I am integrating a GU256x128-3900 on a design. The display is driven in DMA mode on its parallel port.

    For some reason, I am getting  a lot of display errors whey strictly following the timing in the documentation (min 100ns WR low, min 15us WR high before next byte), but found out that if I relax the timing of commands for the first 9 bytes by keeping WR low for 60 microseconds, then I am getting perfect communications with the module. Further bytes do not need this extra 60 us delay.

     Looking at a logic analyzer, everything looks as it should, but without those 60us, the display just doesn't behave properly.

     Is this a known behavior? Or is this a known problem, with a known solution?

   I've been scratching my head on this for a while!

elafargue,

Thank you for your post.

Concerning the display errors and timing, are you polling the RDY signal? It is present in the parallel interface timing diagram on the module's datasheet and essentially changes when the module's receive buffer nears capacity. Polling this signal stabilizes communication if you only send data when the signal indicates that the module is ready.

Additionally, the maximum start-up time (at power-on or module initialization) for these modules is 500ms so you could also try adding a delay of 500ms before you start sending bytes to the module to ensure that you aren't sending data during module start-up. 

If you are still having issues after these suggestions, please post your exact module number so we can assist you further.

Thank you,
Noritake VFD

Thank you very much for your reply,

    We have done more tests on the logic analyzer, and finally managed to fix the problem. There were two separate issues:

      - the root cause for unreliability was the slight delay there is between the positive edge on WR and RDY going down - up to 500ns in the documentation. We were reading RDY too fast after toggling WR, which led to one write operation with RDY being down. The next write operation was correctly delayed until RDY went back up, making this a bit tricky to discover on the trace since it led to only one missed byte.

     - The other issue we had was with a 3900B module on the same parallel bus as the 3900 module. The specs say to wait 15us after writing but not monitor RDY in DMA mode (section 8.1.2 in GU256x128C-3900B HW specification). In our experience, the RDY signal is actually used by the module, and needs to be monitored.  The module is a GU256x128C-3900B, with SW1 switch #6 in "On" position.

Best regards,

Ed

Ed,

It's good to hear that your problem was fixed!

Concerning RDY signal monitoring, RDY needs to be monitored when sending commands but it does not need to be monitored when sending image data bytes. In the datasheet, it specifies in section 8.1.1 that the diagram is "Not applicable for bit image data transfer in DMA mode" and this diagram includes RDY monitoring. In 8.1.2, it states that the diagram is "Applicable for bit image data transfer in DMA mode" and the diagram does not include RDY monitoring. 
For example, when using the "bit image write" command, the RDY signal must be monitored for the command header bytes but not for the subsequent image data bytes.

We apologize that this is quite confusing but we hope that this explanation clears it up a bit.

Noritake VFD

Thank you very much for your support, everything is working great now!