Hello,
I'm looking for some help, I've written some code for this LCD module that uses the SED1335 controller, and am 99% there, but I'm experiencing a bit of a problem. I am aware this could well be just a driver coding issue of my making, but I've almost exhausted all avenues of investigation now so am hoping that the symptoms of my problem will ring a bell with someone out there.
Basically I am drawing a bitmap on screen (approx 50 * 50 pixels), row at a time, using the "command byte+stream of data bytes" (per row) method. Sometimes a problem occurs where an additional 8 (or so) pixels can be written on the end of the row. It *appears* that an extra byte has been inserted during the row write for some reason, since the first byte of the row is always written correctly and the last few bytes seem to have been pushed along by 8 (or so) pixels. I know this looks like a silly coding error, but bear with me!! I've checked the WR strobe pulse and I am not strobing it once too often or anything stupid like that.
What is extremely confusing though is that this behaviour becomes better/worse under certain conditions:
1) It happens much less frequently if I disable the screen (using the command) then do the write, then re-enable the screen, but this is undesirable due to screen flicker. 2) It happens much less frequently if I write only one data byte per command byte, i.e. "command byte+databyte+command byte+databyte...". 3) It happens much less frequently (and this is the biggest puzzler of all) if the data bytes I send tend to comprise of mostly 0s! How can this be?!My code should in theory work the same regardless of data byte values, I've done a quick check for any unusual optimisations etc but can see nothing. Exactly the same code runs in all cases, apart from the described differences. One other thing worth mentioning, when writing data bytes (following memory write commands) I synchronise the writes with the status flag on D6 and write no more than 4 data bytes before the next screen line draw. This should not really affect write reliability anyway though, it's just to avoid momentary distortion on screen.
If anyone out there can offer any advice about what's going wrong I'd be grateful! I've looked at everything I can, the code looks fine, the timings all look fine, it can run for about 15 hours and this problem might only occur 3 times, but I am worried because I can't explain why it happens, and of course it might occur 10 seconds after powerup, not really ideal!!
I don't really expect anyone to figure out my code for me, but I am hoping that anyone who is familiar with either this module or this controller just
*might* have encountered this and know the root cause.Regards, Richard.