I am having severe roblems with the graphic LCDs I would like to use with my Midibox project. I have tried various models from different manufacturers with the Toshiba T6963C controller on it.
The one I am fighting with at the moment is a Wintek WM-G2406D, some info on the pinout can be found here: http://zing.com.tw/WINTEK/wm-g2406de.htm As it is the D version, it only requires 5V input voltage. As far as I understand, VEE is generated on board of the display unit and should be a negative voltage which is supplied via a pot to VO like shown here: http://www.ucapps.de/mbhp/mbhp_lcd7_t6963c.pdf
So far I have connected VSS to J15 pin Vs, VDD to J15 pin Vd. VEE is connected via a variable resistor (10k) to VO. The other “end” of the variable res is connected to VSS. Now, if I measure at VEE I would suspect a negative voltage there, but it is in fact 3.xV POSITIVE (measured against VSS). VO against VSS measures a plain 5.0V also POSITIVE. This must be wrong, right?
But, what is it that I am missing here? Is there any tutorial on GLCDs on the web somewhere so I can dig a bit deeper? Or is my reasoning wrong?
The Power supply I am using is able to deliver 1.4A at 5V, there is nothing else but the core module and the GLCD connected - should be enough. So what else?
It could be, that the FGND pin has to be connected in order to get the internal DC converter running. I would try a direct connection between FGND and Vs (both are ground in your case).
If this doesn’t help, just start with two 9V batteries in order to get -18V. A DC converter chip can be ordered later…
Do you still own the other LCDs? Something which is not explicitely mentioned in my schematic are the connections to chip select and reset line. Even if the negative voltage is available, the display has to be initialized before you will see anything on the screen. Reset must be deactivated (for Wintek: RES=0), and the bus must be selected (Wintek: CE=1).
I tried your suggestions on the Wintek display and I have a partly success. Here is what I did:
connected FGND to VSS (ground)
connected RES to VSS (ground)
connected CE to VDD (+5V)
Also, I have
connected WR to RW of J15
connected RD to E of J15
connected C/D to RS of J15.
All data lines are connected directly.
Now, if I load the ‘lcd7_t6963c_v’ test application (PIC 18F452, MIOS v1.8 ), I can see a static number of horizontal rows - it looks a bit like a bar code :-.
MIOS Studio shows the following MIDI activity coming from the PIC (no other modules connected):
Is there any pattern in this from which one could derive a cause for this behaviour?
And yes, I still have all of the displays; to be precise, I have two of each kind, which makes a total of six. And you gave me some hope of getting them to work after all
the connections are correct (you can compare it against the pin definitions in app_lcd.inc), but I’ve no idea, why the core should send these strange MIDI messages, there is no MIOS_MIDI_TxBufferPut command within the app.
A lot of “FF”, “F8” and “FA” indicate, that there could be spikes of 30..100 uS on the Tx line
It could be related to your power supply - is the backlight already in use? Try it without first
In fact, I have thought about my power supply, because I have recently “lost” some PICs. They were either erased and I had to burn a new bootloader (which should be next to impossible under normal circumstances), or they were completely destroyed. I was using a 5V power supply which was connected directly to the 5V out socket of the core board - the 7805 voltage regulator and the capacitors are not stuffed on the board I was using. I will try it with another core board and another power supply tonight.
Also, the negative voltage schematic from http://www.ucapps.de/mbhp/mbhp_lcd7_t6963c.pdf seems to produce strange output with that power supply, in a sense that if I turn the pot I can change the negative output voltage up to a certain point (but not consistently the same!), then suddenly the output voltage gets stucked and turning the pot does not have any effect anymore.
Tonight I will see if another power supply will solve the problems!
I have exchanged the power supply and I am using a different core board with the voltage regulator installed, so power should be very smooth now.
I have no more random MIDI messages sent by the core module, but the display still shows horizontal lines of varying thickness (and actually the black lines do change, they are not always the same after switching on the core). I can reproduce this behaviour with two different core modules, and it is the same with both test applications (vertical ‘lcd7_t6963c_v’ and horizontal ‘lcd7_t6963c_h’ mode).
I have double checked the connections, all are wired as described and I have also re-soldered them - to no avail. Maybe some of the display’s pins voltages need to be the opposite (like being connected to ground instead of 5V)? But where to start looking?
this bar/stripe pattern sounds like the access to the display is partly working, but the RAM hasn’t been initialized, and font’s are not displayed.
Something like this can happen on a timeout (see app_lcd.inc, search for TIMEOUT). Either your display is slower than the one I’ve tested so far, or two data lines are swapped, so that commands are not forwarded properly.
But I just have noticed another thing: I just have hooked my own T6963C display (donation from d2k) on a MIOS V1.9 core and noticed, that the font is scrambled.
This is realted to a the “font location change” (font is now located at the end of flash memory). This means, that all LCD drivers need to be recompiled with the new mios.h file
This file can be found in the migration/ directory of the MIOS v1.9 source package
And there is another point for which you have to take care about when using a graphical display: the update_with_old_mios.hex and update_without_installed_mios.hex file don’t contain the font, it’s only part of the mios_v1_9_pic*.hex file.
For the case that this is too confusing, here some step-by-step instructions:
- upload mios_v1_9_pic18f452.inc in order to ensure, that the font is available
- copy migration/mios of the source code package into the directory of the LCD driver
- rebuild the application and upload it to the core
Maybe this already helps before fixing the timeout mechanism. I will wait for an driver update until I know, that your GLCD is working
so I will make the switch to MIOS 1.9 tonight. I tried MIOS 1.9 yesterday, but then I had strange MIDI output, thought it was related to MIOS 1.9 and reverted back to MIOS 1.8 .
First I uploaded the ‘update_with_old_mios.hex’ file, to get the new bootloader into the PIC. Then I uploaded ‘mios_v1_9_pic18f452.hex’ from the mios_update_v1_9/pic18f452/midi folder to have the fonts in my PIC.
I copied all of the content of the mios_v1_9_src\migration folder into the lcd7_t6963c_v folder and built a new main file. Then I uploaded the main.hex file to the PIC, but I still get the same behaviour: bars/stripes all over the place :(.
Could it be that the Command/Data input is inverted on my display? Just a wild guess, because you said
or two data lines are swapped, so that commands are not forwarded properly.
Okay, I admit I don’t really know much about this stuff…
I searched all the files in the lcd7_t6963c_v folder for the MIOS_LCD_TIMEOUT0 string, it was only found in app_lcd.inc and in mios.h. Is it actually used in your demo application?
The update procedure was complete, and if the display shows the same behaviour, it is propably related to the driver.
I just have uploaded the new driver versions - app_lcd.inc is still the same, the framework is based on the v1_9 skeleton. All drivers (beside of the IIC driver) have been tested with my own displays, so please use the most recent “lcd7_*_v1_9” versions -> mios_download page (maybe it’s required to refresh the page)
Yes, app_lcd.inc is the right location, the driver is located there. There is a timeout loop, which you could disable (just remove the “bz USER_LCD_WaitUnbusy_Disable” branch) - if MIOS hangs up thereafter, you know that the issue is related to the busy state
Yes, you are right - different polarities have to be considered. I just had a look again into the datasheet of your GLCD, it lists “RD” and “WR”, but no hint about low active signals, they could be high active!
Solution (try this before removing the timeout mechanism): search for “GLCD_RD_N” and “GLCD_WR_N”. Each time a “bcf” is used, turn it to “bsf”. And change each “bsf” to “bcf”
I downloaded the latest ‘lcd*v1_9’ version from the MIOS download site.
I exchanged ‘bcf’ with ‘bsf’ for all combinations of “GLCD_RD_N” and “GLCD_WR_N”, that means for either one of them and for both at the same time, but to no avail. I still have the same bars.
I also removed the timeout mechanism as you described, but I’m afraid I can’t see if MIOS hangs up or not. The display is just showing me the bars, and that’s it. Is there any way to recognize whether MIOS is still doing something (apart from looking at the display)?
This is getting rather frustrating - sigh. I just wish the displays were not so good - I mean the quality of these bars is excellent, sharp and high contrast
There is a simple way to debug the driver: just use MIDI events as “log mechanism”. When you add following code to USER_LCD_PrintChar:
USER_LCD_PrintChar
movwf TABLAT ; save character
movlw 0xc0
call MIOS_MIDI_TxBufferPut
movf TABLAT, W
andlw 0x7f
call MIOS_MIDI_TxBufferPut
movf TABLAT, W
;; ...
[/code]
each character will send out a program change
Best Regards, Thorsten.
I included the code snippet as you suggested. MIOS does NOT hang, after switching on the core I get the following MIDI messages from the core (running the ‘lcd7_t6963c_v_v1_9’ example):
These messages come with a short pause in between them, so I guess the first ‘wave’ is the Copyright screen, and the second is the test screen?!?
Well, unfortunately I still only see these bars…
As I have a second one of these displays, I will be testing whether I already shot the display when having trouble with the negative voltage. This might need a few hours, as I will have to find some connectors for doing this first.
I’ll keep you posted - and thanks for this rather lengthy support…
Yes, these are the strings and the icons which are printed out. There could be another interesting check before you unsolder this display: according to the T6963C datasheet (I just had a look), the CE (chip enable) line is low active. But in the Wintek specs it’s listed as high-active signal. However, I assume that this is an error, and that all three - RD, WR and CE - are low-active signals. This means: CE_N must be connected to ground in order to activate the bus. And you have to use the unmodified driver (no bsf/bcf change)
This could also explain, why there isn’t a change regardless of the RD/WR polarity.
I clamped CE (Pin 7 of the display) to ground, but I still have the bars. The app version was the original ‘lcd7_t6963c_v_v1_9’ example downloaded again from uCapps.
Strange enough, then it looked like the core did not react anymore.
Therefore I included the debug output and removed the “bz USER_LCD_WaitUnbusy_Disable” branch, and what I got was this:
The first three lines are the remnants of the SysEx upload, the rest is a periodical message, received every one or two seconds. PIC erased (?) or destroyed? So I uploaded MIOS again, inserted the “bz USER_LCD_WaitUnbusy_Disable” branch again, but left the MIDI debug output in USER_LCD_PrintChar. Now, the display shows the same bars, and the only MIDI output I get after powering on the core is:
I did some more testing: I exchanged ‘bcf’ / ‘bsf’ for all “GLCD_RD_N” and “GLCD_WR_N”, and now I get the program change MIDI messages after switching on the core again.
So what I have now is: CE clamped to ground, and WR and RD inverted. I still have these bars, but at least I get the MIDI debug output again.
Even if I delete the “bz USER_LCD_WaitUnbusy_Disable” branch, I still get the MIDI debug output. So MIOS does not hang. Only the screen output of the display is still bars…
yes, this makes sense. It seems, that the datasheet is totally wrong, because your observations indicate, that the CE input is low active. I think that RD/WR are low activate as well - and the reset, too!
So: use the original driver, clamp CE to ground and RESET to +5V. I think that this will work
You don’t need to upload MIOS again if the core “hangs up”, normaly this happens if the driver runs in an endless loop (e.g. due to a missing timeout). In this case, just upload a modified application via 1st level bootloader
There is still a little floating voltage problem (or so it seems), the display is only stable if I touch pin 19 (FS) - guess I will have to connect it to VDD or VSS, it should mean ‘Font Select’ I guess.
Actually, it seems like these pinouts are never right. At least this one is giving me the same trouble again… so I should be able now to solve the problem on my own, I thought.
Here is the story:
When connecting it like described on the web page of Data Vision, as usually I get those bars. Now, I tried all combinations of CE / RES clamped to ground / to +5V and I inverted WR and RD. There is one combination (CE and RES both connected to +5V) when I do not get bars, but it looks like some random blocks of (roughly) character size get switched on and off with a frequency of about 0.5 Hz. One can clearly see that the display has eight character rows when held horizontally - the blocks vary in width but are always eight pixels high. And it doesn’t seem to matter whether WR and RD are inverted or not… Is this any indicator to a solution of this problem???
Ahh, and sometimes the display just stays blank… though I changed nothing!?
I know that you may already have enough of these display problems. Well, I just thought you might have another idea of what could be wrong this time…
