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.

AM3352: Probability of parity bit error

Part Number: AM3352
Other Parts Discussed in Thread: AM3354, , AM3359


Regarding the interim progress on the issue of serial port parity errors, based on the current test results, it appears that there is a high probability of a hardware problem. Following your previous suggestion, we have tested the parameters of the power supply as follows.

1. After checking the pins and principles, there is no power supply error in the power supply configuration of AM335X. The bypass capacitor settings are reasonable, theoretically there should be no power supply fluctuations. Below are the ripple tests for the 3.3V power supply to the UART of the CPU board and the VDDS power supply voltage to the IO area.

2.The PMIC output terminal has a ripple of 15.2mV for the 3.3V supply voltage.

3.The PMIC output terminal has a ripple of 15.2mV for the 1.8V supply voltage.

4.The MCU input terminal has a ripple of 16.0mV for the 1.8V decoupling capacitor.

Finally, may I ask for other possible reasons that may have caused this issue? Looking forward to your reply. Thank you!

  • if there is a parity error on uart, I think it is easier to scope the uart signal like tx/rx first? or you have done it already? can you share more on this?

  • The detailed introduction about this earlier.

  • OK, by reading the previous post, you mean:

    1. the am335x uart tx is connect to a logic analyzer

    2. the am335x runs a program and output the same data (0x85? 85?) in a loop to a uart port

    3. the logic analyzer will analyze the received data and label them

    4. the logic analyzer find a frame with correct data but wrong parity bit

    this still miss some detail like:

    1. is the wrong parity happen same pattern every time? I mean every time the data is correct and the parity is wrong.

    2. if the data being send the changed like 0x55 or 0xAA, will the pattern different?

    3. Can the length of the bits being measured to determine the real baud rate?

    4. Can the wrong frame being measured using a scope?

    because the above missing detail, I can't make a strong argument, my guess is this is likely to be a baud rate miss match, do you try to change the baud rate a little like Gary suggested?

  • Hello,

    It's good to hear that you have conducted thorough testing on the power supply parameters and have found no errors in the power supply configuration of AM335X. The ripple tests for the 3.3V power supply and the 1.8V power supply appear to be within acceptable limits.

    Given that the power supply parameters seem to be in order, it's important to consider other potential causes of the serial port parity errors. Here are a few additional factors to consider:

    1. Signal Integrity: Check the signal integrity of the UART lines, ensuring that there are no noise or crosstalk issues that could lead to parity errors.

    2. Grounding: Verify that the grounding scheme of the system is robust and that there are no ground loops or ground bounce issues that could affect the UART communication.

    3. EMI/EMC Interference: Evaluate the system for potential electromagnetic interference (EMI) or electromagnetic compatibility (EMC) issues that could impact the UART communication.

    4. ESD Protection: Ensure that appropriate electrostatic discharge (ESD) protection measures are in place to safeguard the UART interface from ESD events.

    5. UART Configuration: Double-check the configuration of the UART interface, including settings such as baud rate, data bits, stop bits, and parity settings to ensure they align with the requirements of the connected device.

    By examining these additional factors alongside the power supply parameters, you can further investigate and identify the root cause of the serial port parity errors. I hope this information helps, and I wish you success in resolving the issue. If you have any further questions, feel free to ask.



  • Firstly, the data sent via UART is cyclic, ranging from 0x00 to 0xFF. The occurrence of errors is random. There was a table in a previous post showing the test results of one of the products.
    1. The higher the baud rate, the greater the probability of errors. In this case, the data itself is correct, but there is a probability of error in the parity bit.
    2. Every data transmission has a probability of error.
    3. Yes, a logic analyzer can calculate the baud rate by measuring the bit length.
    4. Oscilloscopes are not ideal for capturing sporadic phenomena, unlike logic analyzers.
    5. I have tested our products with AM3352, AM3354, and AM3359, and all of them exhibited this issue. However, when I used the official development board, the problem did not occur (e.g., at a baud rate of 192000, I sent 4800000 bytes without experiencing any isolated parity errors). On the official development board, data becomes scrambled at high baud rates, rather than just having parity errors. Hence, I suspect a hardware issue and would appreciate any suggestions you can provide.

  • Thank you for your suggestions. I will provide feedback to our hardware team to further investigate the root cause of the issue.

  • Hello,

    Ok, look forward to your feedback, thank you



  • Hello,

    We can now rule out hardware issues. Recently, we expanded our testing scope and found that the code runs fine on our product using the official development board, which only utilizes the bare metal UART functionality. However, we encountered issues when testing our product, which uses multiple peripheral devices. Do you have any software suggestions? Could this problem be caused by peripheral device driver issues or any other factors?

  • Hello,

    1. Check the compatibility of the peripheral device drivers with the AM3352 platform. Make sure that the drivers are up-to-date and properly configured.

    2. Ensure that the peripheral devices are properly connected and configured. Check the wiring, power supply, and other relevant parameters.

    3. Use debugging tools to identify any potential software issues. This could include tools such as JTAG debuggers or kernel debuggers.