LCD Short Test v0.1

Testing/Troubleshooting
1

LCD Short Test is a simple application to test if any of the data pins on your

LCD connection are shorting.  It does this by raising each pin individually and

checking if any other pins are receiving the signal.  Your best bet is to

disable the power to the LCD module while you test this.  That’s best for it’s

protection and will prevent the output of false positives due to interaction

with the LCD driver itself.

Currently it does not test the 3 pins from PORTD that are on this port, nor can

it tell if you are shorting against the backlight, power, or contrast pins on

the port.  Only D0-D7.

Possible modifications would be to get it working with the other PORTD pins on

J15, and get it to work with other ports.

Note: Be careful.  You can’t do this to all of the ports, and make sure you

don’t, say, do it to the PORTC pins that are the UART Rx/Tx, since they are the

MIDI connection :).  I did this, and I crashed MIOS, the PIC, and my MIDI

interface all at once!

DISCLAIMER:  You might ruin both your PIC and your LCD module.  Use at own risk.  Personally, I’d wait before using this until one of the senior members says that doing this is a good idea.

How to read the output from the application:

The shorts are reported via MIDI sysex dumps.  I only ever use the lower four bits in each byte so as to avoid using the 8’th bit and confusing the MIDI driver.  In the dump you will see the port (0x0b for PORTB), followed by two bytes, representing which bit we have turned on (ie 0xFE is 11111110 in binary, which means we’ve risen the first pin).  Following is another two bytes, representing the readout on the port (again with the data byte split into two bytes for Sysex transfer).  Let’s say it’s 0xFC, which equals 11111100 in binary.  That means that when we rose data pin 1, it rose both pins 1 and 2.  Therefore there is a short between pins 1 and 2!

Full example:

Sysex message is F0 00 00 0B 0F 0E 0F 0C

Breaking this up, we have:

Sysex header: F0 00 00

Port: 0B (PORTB)

Risen pin: 0F 0E (0xFE, or binary 11111110, meaning pin 0 is risen)

Port readout: 0F 0C (0XFC, or binary 11111100, meaning both pin 0 and 1 are receiving signal)

Meaning: Pin 1 and two are shorting.

Obviously you will always see these in pairs (in the above example, pin 1 will also cause pin 0 to receive signal).

link: http://th0mas.sixbit.org/lcd_short_test_v0_1.zip

Again: Wait until someone says that this should be a safe thing to do before running it.

Cheers,

Tom

2

Going to Wiki - and by You! (ask about permanent filehosting)

Mix and match with “Tracing unknown LCD PINOUT” or do as You like.

Thank You, Moebius

3

Done.

Filehosting is permanent as it needs to be.. I have a second host as well.  If TK or anyone wants to mirror it, go for it.

4

Thanks Thomas, I like the idea! I would like to test this by myself first, if it runs successfull on all my MIDIboxes (with all the different pin configurations), I will copy the package to Page not found – midibox.org Blog

Best Regards, Thorsten.

5

Sounds great Thorsten!

If it ends up being buggy/problematic then let me know and I’ll remove it from here & the wiki.

Note that the commented code is definitely buggy, for example if you uncomment it and attempt to debug all the pins on PORTC you wreck the UART pins and, like I said, crash everything in the midi chain :slight_smile:

If it provides a use I’ll augment it to work the other applicable ports/pins as well.

6

Hi Thomas,

I just have tested it on my MBSID/MBFM (one display) and MBSEQ (two displays)

It works fine on MBSID and MBFM, but I would like to see a “pass message” to know, that the test has been executed. I’ve modified the code in the following way:

void Init(void) __wparam
{
  char error = 0;

  TRISB = 0x00; // enable drivers of port B
  // for more details about the available SFRs, just have a look into
  // the PIC18F452 datasheet, which is available at the Microchip
  // homepage: http://www.microchip.com

  for (i = 0; i < 8; i++) {
    error |= TestPins(0xb, i);
  }

  if( !error ) {
    MIOS_MIDI_TxBufferPut(0xf0);
    MIOS_MIDI_TxBufferPut(0x1a);
    MIOS_MIDI_TxBufferPut(0xf7);
  }
}
[/code]









and I've modified TestPins(), so that it returns a value != 0 if a mismatch has been detected.











On my MBSEQ I noticed a strange effect, for which I currently have no explanation:



F0 00 00 0B 0E 0F 0E 00 F7







(RB0-RB4 are zero, although only RB4 should be 0, and the rest 1)







I would have to open the case in order to do further analysis. I've already added some delays between the PORTB value assignment and the PORTB != TRISB check, I've also assigned the pattern "LATB = ~(1 \<\< pin)" instead, but the result is the same... hm...







Best Regards, Thorsten.
7

Hi Thorsten,

A pass message - great idea.  When I was testing my SID that did not have a short, I only knew that it had passed due to previous knowledge with using the application.  Same with the delay and other modifications.

  As for the “unexplained error” with your SEQ, it could be a couple things.  One thing that I was thinking about is that some LCD modules might respond, since we are sending them data via raising each pin during our tests.  So maybe it’s responding?  The only other thing that I could think of, aside from it being a short ;), is that it’d be due to the dual LCD’s connected - I didn’t look at the schematics for connecting two LCDs to check this, however.

  Funny story, when i was testing the application, I kept getting what I thought was a bug, like what you’re getting with your SEQ.  I stared at the pins and was sure that there was no short, and could not explain it (and was hunting the code and the PIC datasheet for an answer).  Turns out there was a single strand of wire that had gotten caught and shorted the pins together, and I only saw it under a magnifying glass :slight_smile:

Cheers,

Tom

8

Turns out there was a single strand of wire that had gotten caught and shorted the pins together, and I only saw it under a magnifying glass

I don’t want to exclude the possibility, that it is a similar problem at my side. Even though both displays are working fine, sometimes strange things can happen. However, it’s a little bit difficult to get the box opened (because there are some other MIDIboxes at the top :)), but I will check this sooner or later.

Both displays are passive (data lines in high impedance mode) when the enable lines are 0, and this is definitely the case. There might be a difference because of higher capacitances, but I’ve already excluded timing issues by inserting NOPs (see above).

However, thats all I can say to this, I cannot say when I will continue. Maybe somebody else with a MBSEQ could doublecheck the results?

Best Regards, Thorsten.