Announcement

Collapse
No announcement yet.

Goldelox uOLED-160-G2 Intermittently Fails to Respond

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Goldelox uOLED-160-G2 Intermittently Fails to Respond

    Hello!

    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.

    Cheers,
    Andrew

  • #2


    You need to wait for the ACK, the amount of time an image command takes will vary according to all sorts of variables, you must wait for the ACK.
    Mark

    Comment


    • #3


      Hi Mark,

      I actually tested that under Test Case 3: the Python code sending the messages blocks for input from the screen before sending the next message. No further commands are sent until the ACK is received. It would still crash intermittently.

      Cheers,
      Andrew

      EDIT: Just double checked the Python docs to make sure that it blocks and re-ran the tests. Everything still checks out-- the serial port is blocking for input before sending more output, and the tests did reproduce the bug. Interesting to note, however, is that it failed on a draw rectangle command this time around, which rules out Display Image being the culprit.

      Comment


      • #4


        The display has an input buffer so that not consistently waiting for the ACK (or ignoring extra data in responses which might have the appearance of the next command receiving an ACK when it hasn't really) will not necessarily cause an error on the very next command and, depending on time delays involved in sending the next command, could cause the problem to become apparent at different places.

        Please check your code very closely, perhaps try replicating the issue with Serial Commander and checking what it is getting back with what you are waiting for as a sanity check.

        If you can get a log of a failing command sequence maybe you can post it here
        Mark

        Comment


        • #5


          Hi Mark,

          I've updated my Java program to wait for a full response (with length varying on the type of command) from the screen before sending the next command. As far as I can tell, it performs to the specifications that you are requesting. I can still reproduce the bug, albeit less frequently. It still hangs after repeated testing.

          To be clear, you want me to reproduce the bug using the Serial Commander tool that is accessible from the 4D Workshop? As in, the graphical tool where I manually select each command and send it one at a time?

          Thanks,
          Andrew

          Comment


          • #6


            To be clear, you want me to reproduce the bug using the Serial Commander tool that is accessible from the 4D Workshop? As in, the graphical tool where I manually select each command and send it one at a time?
            Not necessarily, if you add logging to your Java App, so it looks similar to what you get with Serial Commander, that will be fine.
            Mark

            Comment


            • #7


              I've attached two logs for your perusal-- one is the hex values sent (not their ASCII equivalents, but I can provide that if you would like) and the other is a human readable list of messages sent. Java messages have a single equivalent SPE function, with one exception: Draw Rectangle and Draw Filled Rectangle SPE functions have been combined to one Java message which is translated into the correct hex when it is written to the serial port.



              Cheers,
              Andrew
              Attached files screenOutHex.txt (11.9 KB) screenOutPlain.txt (24.7 KB)

              Comment


              • #8


                That's a good start, I also need to see the responses from the display mixed in with that, eg

                FF 68 00 02 [06]
                FF D7 [06]
                Mark

                Comment


                • #9


                  I've attached more log files with responses: one set that shows a single successful run and one set that shows an error run. You will note that the error file does not have a response for the final command-- this is because it hung indefinitely and never sent a response.

                  I didn't include responses in the human readable files, but they are matched to the hex logs that do have responses so I'm sure it should suffice.


                  Andrew



                  EDIT: For the record, the spaces after the responses are a result of the file creation and were not sent as part of the response.
                  Attached files hexLog_error.txt (6.3 KB) hexLog_noerror.txt (15.1 KB) humanReadableLog_error.txt (10.3 KB) humanReadableLog_noerror.txt (24.7 KB)

                  Comment


                  • #10


                    I can't spot anything obviously wrong with the commands or responses.

                    The only thing that is NQR is that on Goldelox images should always be displayed when the display is in native mode, however I'm not sure whether that will cause issues with the 160-G2 and normally I would just expect to see screen corruption with this issue and nothing more.

                    What baud rate are you using?

                    How long are the wires between your driving system and the display?

                    What is the power supply voltage where it enters the display?

                    Can you post the image suite you are using 'changed into colors', or something so that I can replicate the commands being sent exactly (or maybe email the unaltered set to mark at 4dsystems dot com dot au)?

                    What make and model of uSD card are you using? Can you try a different card?
                    Mark

                    Comment


                    • #11


                      Hi Mark,

                      I'm afraid I don't see anything in the PDF documentation about native mode. Could you expand a bit on how to set the screen to that mode so I can be sure it isn't the issue?

                      I've set the baud rate of the screen to 115200, but have also tested it and had it hang at 9600. Both of these were set as the default baud rates, not changed with a serial command.

                      The USB cable is approximately two feet long, but it's worth noting that I verified the incoming commands using a separate USB to serial adapted hooked into the adapter attached the to screen. The incoming data that the second adapter recorded was identical to the data that I recorded on my machine before sending it. That is to say that the screen adapter is getting the same commands that I send, meaning that the problem does not appear to lie in either the software serial interface or the cable itself.

                      The power supply voltage is 5V.

                      I'll go ahead and send you an email in a few minutes with the graphics and their locations on the SD card. For good measure I'm also sending the code that controls the generation of the image write messages. I had to reverse engineer the image format (How much easier life would be if those screens weren't already mounted!). I can't think of a scenario where a wrong image format doesn't fail catastrophically every time, but anything is possible.

                      The SD card is a Transcend 2GB MicroSD card. I've reproduced the error using another card of the same model, but unfortunately don't have any different model SD cards on hand.

                      Comment


                      • #12


                        I had to reverse engineer the image format (How much easier life would be if those screens weren't already mounted!).
                        Why? They are documented in the FAQ section of this forum.

                        What do you mean by the second bit?

                        The SD card is a Transcend 2GB MicroSD card.
                        That's probably it, I have two Transcend cards and they both exhibit 'random' 'power cycling' issues when used in SPI mode. I have a Windows SPI mode reader and it if I copy a file to them or from them Windows keeps 'seeing' them being unplugged and replugged.

                        The native orientation for Goldelox is the orientation it starts in, for the 160-G2 that is landscape.

                        If you use ViSi to generate your screen images and paste the code, you will see how it adjusts the orientation back and forwards for you. It is possible the 160-G2 isn't adversely affected by the wrong orientation, I'll know in a little while when I try your setup.
                        Mark

                        Comment


                        • #13


                          The 128-G2 does suffer from the orientation issue common to Goldelox, but not as bad as some.

                          I suspect you didn't notice it because of the way you generated the images yourself, because you hadn't come across the FAQ you effectively reverse engineered in a way such that it appeared correctly in the Portrait orientation (to see what I mean, try displaying one of your 'non square' images in Landscape)

                          I wrote a short routine to cycle through 10,000 Set Address, show image pairs, similar to your logs. There was no issue found at 115200 baud.

                          I'm confident the issue is with the uSD card.
                          Mark

                          Comment


                          • #14


                            Why? They are documented in the FAQ section of this forum.
                            Whoops! My apologies-- I was looking in the SPE Documentation PDF and came up short. The second bit is a problem on my end-- I already have a dozen screens seated in place with SD cards not accessible. I was hoping not to have to unmount the screens to mess with the cards, but it's looking like that will be unavoidable. For the record, I have a single screen that isn't in place for testing purposes.

                            I have to admit I wouldn't have guessed that the SD card brand would be the problem-- I just chose a card that was less than or equal to 2GB and supported SPI. Do you have a list of other brands to avoid, or a list of recommended brands? I see there is a post about it in the FAQ about the SD cards with a few brands listed, but I don't see any sort of official comprehensive list.A cursory forum search indicates that Sandisk the best bet. Is this the case?

                            I'm afraid I'm not really following what you're saying about screen orientation. I'm aware of the issue with displaying images in Landscape (I posted about it in this forum a few weeks ago) and I came to the conclusion that without physical access to the SD cards ViSi wasn't an option and the best plan was to simply rotate the images before writing them to the card. Upon doing so it seems to work correctly-- the images are displayed in the correct orientation and position. Is there another reason I should not be doing this?

                            Cheers,
                            Andrew

                            Comment


                            • #15


                              A cursory forum search indicates that Sandisk the best bet. Is this the case? We have not seen a SanDisk that didn't work. We also sell Phison from our site, because we have tested these and we know they are coming direct from the manufacturer, not through some third party chain that we have no control over.

                              We have many times thought of creating a list, but when you have two cards purchased at the same time, from the same manufacturer, one of which Windows recognises in an SPI reader and one of which Windows doesn't, you begin to wonder just what use such a list would really be.

                              I'm afraid I'm not really following what you're saying about screen orientation.
                              Some Goldelox display models, when in non-native orientation end up writing the first 'scan line' last, eg
                              2
                              3
                              4
                              5
                              1
                              Since you have tested the 160-G2 and found it is not doing this, then fine, continue doing it the way you are, just be aware if you change to another Goldelox display model, that the images may not appear the same.
                              Mark

                              Comment

                              Working...
                              X