LCD 2x20 Init problem

[PG]

Hi,

I read every single post about LCDs on the forum but I haven't been able to get this working. I'm using a Displaytech 202A 2x20 LCD that I got from Mike's Shop (so I'm supposing that it's fully compatible with MIOS) along with a preprogrammed PIC, uploaded MIOS (update_without_installed_mios.hex v1.9c) without problems it's up and running responding with the right sysx msg upon query, the LCD though presents the uninitialised black first row screen "most of the time", yes because every once in a while it initializes correctly showing the Copyright msg and the application screen, the application is always running OK even when the LCD isn't as the core sends MIDI msgs on DIN toggles. This "once in a while" isn't deterministic, even waiting for the caps to discharge before re-applying power doesn't imply that it will work (ruling out reset problems??). The connection between core and LCD has been tested millions of times and is correct, the LCD doesn't seem broken as when it initialises it is stable and works correctly. Vdd on the LCD is 4.97V, RS 3.06V, after startup; during startup with the LCD cable not connected core R/W pin toggles with a 3V swing E pin 5V swing, but with the cable connected the swing is only 0.3V-0.7V even if there are no shorts.

Sending: (communication with the LCD) F0 00 00 7E 40 00 0D 02 00 0B 0A 00 00 00 01 00 00 00 00 F7

Returns: F0 00 00 7E 40 00 0F 04 00 F7

Sending: (LCD type, MIDI interface, core frequency) F0 00 00 7E 40 00 0D 02 00 00 00 00 00 00 01 00 00 00 00 F7

Returns: F0 00 00 7E 40 00 0F 01 00 F7

Sending: (LCD option #1 and #2) F0 00 00 7E 40 00 0D 02 00 0A 78 00 00 00 02 00 00 00 00 F7

Returns: F0 00 00 7E 40 00 0F 03 07 02 04 F7

Sending: (LCD timeout state) F0 00 00 7E 40 00 0D 02 00 0B 12 00 00 00 02 00 00 00 00 F7

Returns: F0 00 00 7E 40 00 0F 0F 07 0F 07 F7

I'm lost, please help.

Thank you in advance. Regards.

Paolo

[HL-SDK]

Have you uploaded MIOS successfully?

[PG]

Well,

during the upload of MIOS using the file update_without_installed_mios.hex (v1.9c) I've got the following messages:

Starting upload of update_without_installed_mios.hex

Hex file contains code in MIOS range, forcing reboot!

Received error code 01: Less bytes than expected have been received

This was an expected error - please ignore!

Received Upload Request

Sending block 00000000-000000FF

Received error code 05: Write access failed (invalid address range) - used by 1st level bsl

...

but after that the upload process didn't stop and after the whole file was sent I received:

00000005694764 ms | [D0 1A 00] Channel 1: Channel Pressure value: 26

which means that the bootloader was installed successfully, as I read in a post by Thorsten.

After that, rebooting the core produces:

00000006883224 ms | Sysex message: F0 00 00 7E 40 00 01 F7

00000006885120 ms | [D0 1A 00] Channel 1: Channel Pressure value: 26

and the LCD is uninitialized showing the black first row. The key pressure countdown messages shown in the readme sect. A didn't show up though. If I upload an application it works i.e. ain64_din128_dout128 V2.0 sends DIN changes as MIDI msgs, but the LCD does get initialized only "once in a while", I cannot specify after how many reboots or after how long it has been shut down because it seems random!?

Thanks

Paolo

[smashtv]

Hi PG

Did you have use feedback from CORE enabled during your MIOS upload attempt?

I don't know if it has anything to do with your LCD init issue but you need to be using "mios_v1_9c_pic18f452.hex" instead of the without_MIOS_installed file.......it is for PICs with older bootloader versions.

All of this is covered in detail in "README.txt" in the MIOS zip file.

Best

Smash

[PG]

Hi,

yes I used the feedback, and I also uploaded "mios_v1_9c_pic18f452.hex" successfully. After a series of reboots I was able to see the "READY." msg but on the next reboot the LCD didn't initialize. If I upload an application it works, I see the MIDI output and when the LCD initialises correctly I can see the "GUI".

I'm currently testing the Core module with LCD, 1 DIN, 1DOUT, 1 Bankstick attached, AINs clamped to GND, anything else unconnected, except the MIDI ports, but I also tested it with just the LCD and got the same results, is it OK?

Regards.

Paolo

[smashtv]

Hi PG....

Since it acts the same with just the LCD, and the I/O looks right when the LCD is not working, I would suspect these as cause:

-Dodgy LCD cable- it is obviously wired right, but one or more connections might be loose enough at startup time when the init is happening....I would specifically look at the enable line, and for any lines that are close to touching at both ends....

-Soldering issues- How does the soldering on the pinheader(s) look?  Sometimes a reflow (re-heating all connections) cures unseen bridges and weak connections.......

-Defective LCD module- This is extremely rare but it does happen....since it works right some of the time I really doubt the module is the cause.

Side note:  I have seen LCD modules on commercial equipment not startup due to failing switching power supplies (super noisy +5 rail) but since you were able to re-upload MIOS i'm guessing your PS does not have ramp up issues.  ;)

Hopefully a quick reflow will make it play nice.  :)

Best

Smash

[audiocommander]

Side note:  I have seen LCD modules on commercial equipment not startup due to failing switching power supplies (super noisy +5 rail)

I might also be that the voltage is not high enough!

I experienced this lately when I plugged in some more sensors. The LCD did show only the initial blank bars. Increase the Voltage from 7.5 V to 9 V solved this issue.

Please note though, that you shouldn't use more than 10 Vs. And please use a Multimeter to measure the voltage you send to the Core, because the printed numbers (on the universal power supplies) are often 2 to 5 Vs below the actual voltage.

Regards,

Michael

[lylehaze]

How long is your cable from the core to the display?

LyleHaze

[PG]

Hi,

Thank you gentlemen for your replies.

My Core with 1 DIN, 1 DOUT, 1 Bankstick, and the Displaytech 202A 2x20 LCD attached, needs at least 6.2V to correctly initialize the display.

I'm not sure if it's a good idea to permanently run my core at 6.2V even if the datasheet of the PIC gives 7.5 as absolute maximum rating.

Thanks. Best regards.

Paolo

[stryd_one]

Well that's about right... the 7805 needs a couple of extra volts, you should generally feed it around 7V :)

[PG]

Hi,

well no I din't mean that, the 7805 was fed with the appropriate tension to regulate it's nominal 5V output, but these 5V weren't enough for the circuit I had to remove the regulator and feed the cirucuit with at least 6.2VDC from my bench variable PSU.

Regards.

Paolo Garuti

Edit: I've just finished testing my core with another LCD, Ampire 2x16, and it worked without problems with the on board 5V PSU, so it may be that my 2x20 is faulty. Is anyone using the Displaytech 202A with success? I'm not sure if it's a good idea to permanently run my core at 6.2V even if the datasheet of the PIC gives 7.5 as absolute maximum rating.

[PG]

Hi,

first of all I must say that I'm a Java and C programmer (well... still a student) and I don't know pretty much anything about ASM, but not willing to power my core with 6.2V, and before blaming it on the LCD I thought that maybe I could look for some timing issues in the LCD init procedure so I was looking into the ASM code in mios_cldc.inc and I tried to add:

movlw 1 ; 1 ms delay

call MIOS_Delay

right after the labels of the MIOS_CLCD_Strobe_Set and MIOS_CLCD_Strobe_Clr routines (I used MIOS_Delay because adding tens of nop lead to nothing). And guess what my LCD started working at every startup, I can see the characters appear with a delay. Obviously I think that that's the dirtiest hack ever done and I admit that I have no idea about possible side effects, I already noticed some problems after uploading new applications the core won't reboot. I'm asking some of the more knowledgeable people if my findings have any meaning and could be used to solve my problem.

Thanks.

Paolo

Link to the datasheet of the Displaytech LCD: http://www.displaytech.com.hk/pdf/char/202a%20series-v11.PDF showing timing diagrams.

[TK.]

I'm using Displaytech Displays in nearly all of my MIDIboxes

The minimum cycle time of the enable line is 500 nS, so the timings used by MIOS are not the real issue here. Adding a delay of 1 mS will have the unacceptable side effect, that the whole system will run so slow that data loss at the MIDI input can happen (as you already noticed).

I cannot add more than already written by SmashTV and AC

Best Regards, Thorsten.

[ilmenator]

I know that this thread is a few years old...

...however, I seem to be running into a similar problem. After meeting Wilba a week ago or so, I was motivated enough to finally get out my MB-6582 and finish the main board. I have a Displaytech 204B BC BC 4x20 display connected to the first core and it shows the exact behaviour as described by PG above.

1) Power is not an issue on my build. The board is driven by a 12V AC linear PSU (originally used to drive a Creative subwoofer and surround loudspeaker set), 12V and 9V are generated by 78xx series voltage regulators. 5V is generated by a Traco TSR-1 series switching mode regulator directly from the rectified 12V source. All voltages are clean and measure exactly 5V, 9V and 12V as they should.

2) Core is up and running. When I switch on the synth, I can hear the start-up sound, I can play MIDI notes, etc. Uploads are successful, latest version "midibox_sid_v2_040/setup_mb6582.hex" is running. MIDI communication works as it should, audio out as well.

3) The display is brand new, the cable is triple checked and built according to the PDF-instructions by Jim Henry.

4) Display is only initialized correctly occasionally. Usually, I get the two black bars when switching on the device, followed by a short flickering, and again the two black bars in the first and third line. Occasionally, the MIOS 1.9g message is displayed, and after a flickering the two black bars appear again. Very seldomly, all initialization goes well, i.e. I get the MIOS 1.9g startup message, and after the flickering the display shows the "E002|PInt Ld Chn. 1" message as it should. That works maybe one out of 30 times.

5) The same basically holds true for the other remaining cores. If I connect the displays there I get the same behaviour (obviously, the backlight does not work on these, and as my control surface PCB is not assembled yet, I only get the message from the PIC ID Change app that I uploaded - the MB-6582 application has not been cloned to the remaining cores yet).

I have ordered a different display, but I would still be curious as to what the cause of this behaviour might be? Quality issues at Displaytech's side? Critical timing in the display init routines? I know this should not be the case after so many years and so many displays being initialized correctly...

[Hawkeye]

Hi Ilmenator,

I´d guess, the display might be slightly off-standards, and those 4-line displays seem to be more affected than 2-line displays...

Me haz experimented with a 4x20 OLED and a 4x20 VFD in the MB-6582, and both needed driver adjustments. Both were advertised as HD4.... (can´t remember the number :-)) compliant, but they were not... In the process of driver hacking (and enjoying PIC assembler, hats off to TK. for writing the whole MBSID V2 platform in that language :-)), I fried the OLED, but managed to get the (expensive) Noritake VFD up and running :-).

Why are the 4-lines displays more affected? I remember success reports from 2x20 OLED owners, which worked flawlessly in a MIDIbox without driver adjustment... also, I transplanted a 2x20 OLED into a Waldorf Micro Q (closed source, no driver adjustments possible :-)), which also worked without problems...

Edit: as the display initializes sometimes, it still also sounds a bit like a power problem. I once had this nasty 5V undervoltage problem (VFD is very 5V hungry) with the old C64 PSU, where the PICs in the MB6582 slow-booted reproductively... ca 60 seconds from turning on to MB6582-patch display - still faster than my average PC, but... ;-). Can you turn on the MB-6582 and monitor the 5V lane with an oscilloscope in slow-motion (it could be a too small ripple smoothing capacitor in the psu) ?

Bye,

Peter

Edited July 20, 2012 by Hawkeye

[ilmenator]

Unfortunately I do not have the equipment to monitor the 5V lane in slow motion. However, the board's behaviour is the same with 3 PICs removed (=only 1 PIC in place).

The ripple smoothing capacitors on the 5V lane should be large enough - actually, C3 (2200µF) and C4 are smoothing the 5V lane in my design, see MB-6582 base board PCB. V1 has been replaced by the Traco 5V regulator, and C2 has been removed due to space constraints. That should be uncritical, as the Traco does not require any capacitor on the "primary" side for input voltages under 30V, according to their data sheet, and there is still C1 (2200µF).

Also, the probability of a successful init does not depend on how long the board has been switched off - in other words, even if I remove the power only for a very short time this does not help the initialization of the display.

[ilmenator]

So I measured the current draw with two PICs inserted, and it settles at 260mA with the LCD backlight on (230mA with only one PIC inserted). The Traco should deliver 1A, and I could not find anything about a startup ramp or something like that in the data sheet. Even if the current draw is much higher on startup, say factor two or three, I should still be on the safe side.

[Hawkeye]

Strange, indeed! Do you have any other character display to test with? Any 2x20 or even a 2x16 should work to see if it initializes correctly... Only other thing I can say is that the MB6582 uses a 4-bit access mode for the display per default, which caused some problems with my non-lcd not-100% standards compliant display experiments... but... it did never work, it was not "flaky" as in it works one in three times or so... maybe replace the display cable to make 100% sure there is no bad solder joint or broken cable?

Bye,

Peter

Edited July 21, 2012 by Hawkeye