This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

PROCESSOR-SDK-AM335X: Uart data bit parsing after frame error

Part Number: PROCESSOR-SDK-AM335X

Dear sirs,

I have configured am335x UART setting as 9600, 8n2 to communicate with an external device with the same setting.

But this device don't response as configured setting, it only send one stop bit at end of frame. (Captured waveform as below)

Expected data sequence should be 0x3A, 0x30, 0x31, 0x38 with frame error, but am335x UART report data as 0x3A, 0x14, 0x84, 0x34 as marked.

I want to know if any UART setting to fix data bit parsing to what I expected to be? Thanks

  • Hello Kuanlun,

    Are you using Linux or RTOS?

    Regards,

    Nick

  • Hi Nick,

    I use Linux, thanks

  • Hi Kuanlun,

    My understanding of the issue is that when both AM335x UART and the external device are configured to 2-stop-bits and sending data to AM335x UART, AM335x UART doesn't interpret the stop bits correctly. Is my understanding correct?

    Which Processor SDK Linux version do you use?

  • Hi Bin,

    Yes, it seems AM335x UART doesn't interpret stop bits as what we expected.

    Our product connected to many external device through UART, and some device just did not send data as configured format.

    We want to know if there is a register bit to change this interpret to let us get correct UART data.

    Or I can find some doc about how AM335X UART interpret if frame error detected to convice my customers.

    We use an older SDK version v2.0 but I think this is a HW issue not related to kernel version.

    Thanks

  • Hi Kuanlun,

    Sorry but I am confused by your message.

    kuanlun chiu said:
    Yes, it seems AM335x UART doesn't interpret stop bits as what we expected.

    This sounds the issue is in AM335x UART, but

    kuanlun chiu said:
    Our product connected to many external device through UART, and some device just did not send data as configured format.

    this sounds the issue is in the connected UART device.

    kuanlun chiu said:
    We want to know if there is a register bit to change this interpret to let us get correct UART data.

    The number of STOP bits is configured in LCR register bit2. But please note that the register is handled in the kernel UART driver, The user space application should only use TERMIOS settings to configure the number of the STOP bits, and only change the setting right after opened the UART port and before any UART read/write. Changing the UART port configuration including the number of STOP bits during UART data access could lead to undefined behavior.

    kuanlun chiu said:
    Or I can find some doc about how AM335X UART interpret if frame error detected to convice my customers.

    The AM335x TRM UART chapter describes how the UART module works.

  • Hi Bin,

    Thanks for your reply.

    Yes, I know the root cause is the connected UART device didn't send correct UART frame as configured.

    But AM335x UART data bit parsing rule is a little strange for this stopbit error.

    As the waveform I posted, the device sent 0x3A, 0x30, 0x31, 0x38 with each byte having stopbit framing error.

    (Correct waveform should be two bit high at end of ecah bye but the device sent one bit low and one bit high)

    We have test the same error condition with other CPU like Samsung and Renesas, their UART module can still report corrected data sequence.

    But AM335x UART report it received 0x3A, 0x14, 0x84, 0x34

    I'm wondering if AM335x have some special register bit to configure data bit interpret.

    The AM335x TRM UART chapter did not describes how the UART module parsing next byte when framing error is detected.

  • Hi Kuanlun,

    The UART data format is 8-bit data, no parity, 2 stop bits (but first bit is low, 2nd bit is high), right?

    I think you probably can workaround the issue by configuring AM335x UART as 8-bit data, 1-bit parity (forced to 0) and 1 stop bit. Please see TRM Section 19.3.8.1.3.1 Frame Formatting for details.