I'm working on Goldelox uOLED-160-G2 over serial with SPE rev 1.1 and I'm running into an intermittent problem in which the screen fails to respond to a serial command and hangs until hard-restarted. It seems to fail on a display image image command, but most of the commands I send are display image commands so I'm not certain if that is a coincidence or relevant to the problem.

To reproduce the problem, I sent an identical series of commands to the screen under different conditions. The command list started with screen orientation, clear screen, media init and screen saver messages. During this period, the commands were given ample time to complete. It then looped over a series of change pointer and display image messages about a hundred times. It also drew some rectangles. If you are curious, here are the hex commands that I sent: http://pastebin.com/HGu7EVpe Unfortunately I can't provide the graphics that I used, but suffice to say that they were all within the bounds of the screen and (as far as I know) properly formatted on the SD card.

During most iterations of the tests (perhaps 80-90 percent of them), the program would run without incident. The remaining test runs would not respond to an arbitrary display image message and hang indefinitely until reset.

I've reproduced the problem with two separate programs sending the commands, which I will detail below:

Test Case 1: Java Using Fixed Wait Delays
In this test, I sent the serial commands using homebrew Java program. It waits a fixed time (which I varied between 10 and 100 ms) before getting input from the screen but otherwise sends the commands as fast as possible. This reproduced the problem, but did not rule out hardware or Java problems (I'm using some odd libraries for serial).

Test Case 2: Java While Sniffing Output
I ran the Java program under two hardware configurations: one with a 4D systems micro USB PA5 serial bridge and one with a SparkFun serial bridge which which I had lying around. Both hardware configurations produced the problem. I also sniffed the serial data on the PA5 bridge to verify that the commands were being send correctly from my program and found that they were. This ruled out hardware as a problem (up until the screen, that is!) and superficially validated Java. To be sure, I rewrote the program in Python.

Test Case 3: Python Using Blocking
In this test, I send the serial commands using a Python program. Instead of waiting a fixed amount of time for a screen response, it would block until receiving input. I did not vary the hardware configuration on this test setup, but still reproduced the problem at a roughly equivalent rate. The purpose of this test was to verify that the problem was neither Java side nor related to the input blocking vs delaying.

Has this behaviour been observed in other units? I have to admit at this point I am bit stymied about the cause of the problems.