Post Go back to editing

UART data loss

Category: Software
Product Number: ADUC848
Software Version: Keil

Hello.
There is a problem with data loss in UART communication.
If the end of the received (RX) string is LF (0x0A), we sent it again (TX) without LF.

For example
*IDN? + LF = When receiving a total of 6 bytes
*IDN? = Send a total of 5 bytes.

This action continues at about 30 ms intervals, and the bit breaks about 1 to 3 times a day.
The image is the Scope waveform when the problem occurs.

Below is description of the Scope waveform
C1: set the trigger signal at low when a problem occurs.
       it generated if it is not a promised *IDN?
C2: TX waveform of MCU.
       Send data(*IDN?) collected by RX for verification as it is.
       After that, about 40 bytes will be sent as a result of processing for *IDN?
       The important thing is that one bit of data is broken when sends the received data as it is.
C3: The RX waveform of the MCU.
       Receive *IDN? + LF 6byte from PC Application.
C4: it generated in Low when Read/Write to E2PROM.
       The measured waveform is not close to the E2PROM.
M3: RX waveform of MCU when it’s normal.
Z2: Zoom In waveform of C2.
Z3: Zoom In waveform of C3.

I marked the part in question in a red box.
When it is a normal receiving waveform, the TX output waveform is broken by 1 bit by Echo.
Actually, in F/W determines that it is wrong data.
As mentioned above, these symptoms occurs about 1 to 3 times a day.

In F/W, if a receive interrupt occurs, we only get the 1byte value of SBUF, but there is no part that re-process by bit.
In other words, return (Echo) the value of SBUF as it is.

In my opinion, I think that the MCU is handling it incorrectly rather than the F/W bug.

Parents
  • Hi,

    In your example, does this mean that F/W can determine that the last byte is the wrong data?

    *IDN? + LF = When receiving a total of 6 bytes
    *IDN? = Send a total of 5 bytes.

    The clock of the MCU could be affecting the UART (clock jitters), causing the wrong or missing byte during transmission.

    In my opinion, I think that the MCU is handling it incorrectly rather than the F/W bug.

    Regards,

    Karl

  • Hi Karl.0

    All 100 sample PCBs showed the same symptoms.
    At first, I thought it was an F/W bug, so I tried various things.
    But it didn't solve the bit breaking.
    I was also suspicious of the slight error of XTAL and the increase in error due to PLL.
    So, there was a random temperature change in the XTAL.
    No symptoms appeared.
    I ask for your help me.

Reply
  • Hi Karl.0

    All 100 sample PCBs showed the same symptoms.
    At first, I thought it was an F/W bug, so I tried various things.
    But it didn't solve the bit breaking.
    I was also suspicious of the slight error of XTAL and the increase in error due to PLL.
    So, there was a random temperature change in the XTAL.
    No symptoms appeared.
    I ask for your help me.

Children
  • I want to clarify that there is no bit breaking at a certain temperature? The external oscillator could be causing the data loss if the temperature is causing the bit breaking.

    You may think to consider the power supply as well. A poorly regulated supply could cause data loss in UART.

    Can I ask how you are handling the received data? Are you storing it in the E2PROM?

    You mentioned that you return (Echo) the received data. Does this mean that when receiving data, you are transmitting it back immediately and not reading from the E2PROM?

    You mentioned that the F/W determines that it is the wrong data, could retransmitting the data compensate for the data loss?

  • Thank you for your reply.
    I used a heat gun on XTAL to raise it to 60 degrees.
    Then spray coolant was sprayed and drastically lowered to zero degrees.
    No data loss occurred.
    I used Linear DC Power Supply for power supply and added 100uF + 0.1uF to PC Board.
    When you look at the UART waveform, there is not enough noise to cause bit damage.

    I know the problem with the E2PROM, so I don't use it during communication.
    The received data is stored in the RAM Buffer.
    Echo made sure that the stored buffer value was returned except for the last LF (for error detection purpose)

    I am currently communicating at 38400bps, but I have the same symptoms at 9600bps.

    I am testing the stop bit by changing it to 2 bits.
    It is not supported by ADUC848 but 100us Delay was given after sending 1byte.

    And I disabled all interrupts and only UART is enabled.

    I am observing and I will share the results.

    I'm thinking of a test F/W that can only communicate if it doesn't improve.