Announcement

Collapse
No announcement yet.

Intermittent UART failure

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

  • Intermittent UART failure

    I mistakenly posted in the old forum. I'll duplicate it here.
    I'm a developer and have been using the display, uOLED-160-G2. Recently I have been experiencing intermittent UART failures and have been unable to locate the source of the error. I have 10+ of these displays currently in use and the failure rate varies across these devices. Some hardly fail, others fail around 2-5 minutes of operation.

    I started off with uOLED-160-G1 and first noticed this problem when using a switch mode wall wart. At the time, the problem only surfaced when not connected to an additional ground source (my programming cable or the on board USB connection). I temporarily fixed the problem by switching to a battery supply. This led me to believe it was a power issue but I couldn't find any issue with my supply. The uOLED-160-G2 was released shortly after and I upgraded and the problem seemed to go away until now.

    I am still running off a battery supply (x4 series connected CR123's) through a 5v LDO regulator (ZLDO1117G50TA) and on to the display with a 22uF bypass cap. The display is connected through 6 feet of cable (shielded differential pair). The source is a dsPIC33e that uses two UART resources at a rate of 115.2K baud. One to the OLED and the other to a arduino pro mini, both go through the same cable, the same type of buffer, but on separate differential pairs. The arduino works without fault.

    The buffer attaches information to the relevant command to be sent, for instance the TX length and the expected RX length. The buffer handler sends the command and then waits until the response buffer is filled and then determines the appropriate host response.

    I have tried various handler responses to a failed command. I've tried re-sending the failed command as well as ignoring the failed command and just send the next command. I've tried adding in delays with no avail. The display becomes unresponsive and requires a reset.

    Everything displayed on the screen is text with various colors, sizes, positions. I am not using a uSD card. The initial write fills the whole screen with text and continues to update at most 2-3 lines on the screen at a rate of 4 Hz.

    I have a feeling that it has to do with the stability of the ground with respect to the signal lines, but have not found a solution. A full reset is not an adequate solution. The initialization takes too long for this application. Does anyone have any suggestions on what I might be missing?

    Thanks in advance,

    EP

  • #2
    In the other forum you posted in the SGC sub forum, so I'm guessing you are using SGC.
    Can you show us a circuit of how everything is connected? (i.e. to show what sort of differential system is in use and how the gnd is connected)
    Can you connect another display with the RXs in parallel? (Do both stop at the same time in that case?)
    If there has been some sort of communications error, usually (slowly) sending an autobaud (SGC only) until a response is received is the best way to get the devices back in sync.
    What about some method for logging exactly what the display is receiving and sending?
    Mark

    Comment


    • #3
      Yes these displays loaded with SPE2 rev1.1. I was unaware that an auto baud signal could be used to reestablish the connection. I'll have to try it out and see if it works.

      I believe I have identified the issue. I connected a display directly without the differential pair and the display works fine. The culprit was a faulty cable. I still get an occasional errors, but at a rate that is manageable.

      I'm not sure why the display is more sensitive to communication errors over the arduino, considering the RX line is idle during transmission to the display. I'll have to do some more testing to see where this error is coming from.

      Thanks

      Comment


      • #4
        For SPE it would be better to send nulls (0x00)
        Mark

        Comment

        Working...
        X