Communication breakage between nrf52840 chip and host (imx6ull on stress testing)

Upon stress testing of the thread layer communication over a period of time (around 30 mins to 1 hr) the communication (over UART, 115200 baud rate) between the host (imx6ull based SoC) and nrf52840 chip gets disconnected and it does not recover until otbr-agent is restarted.

Continuous commands were sent from controller to the development kit to reproduce the issue.

1. 868b8d791fac9752d154ef0f0614ca15019056a9 - otbr-agent commit id (github.com/.../ot-br-posix)
2. IEEE 802.15.4 hardware platform - nrf52840
3. Build was done using Yocto recipe.
4. Network topology - Star topology (direct communication between controller and development kit)

Expected behaviour is no communication between the nrf52840 chip and the host(imx6ull based SoC).

Should we raise the transmit buffer size and if we can how can it be done?
Or is there any way to increase the tx timeout of a packet to higher value and will it help resolve the issue.

  • Hello,

    I spoke with our Thread Team. They wanted to ask you a few questions regarding this issue:

    1: Is it a possibility to change the UART baudrate from 115200 to 1000000? When the baudrate is 115200, then the radio is capable of delivering more data than the UART can handle, so the issue could be that this is overflowing, and in that case, the Flow Control will not help, because data is lost due to a UART TX buffer overflow on the nRF.

    2: Regardless of whether it is possible to change to 1M baudrate on UART, where/how did you set the baudrate on the nRF's UART?

    3: They also asked about more details on What/how you are building using Yocto. We assume that it is the border router itself (not the nRF) that is built using Yocto. Can you please verify that? And can you share some more details on this?

    4: And can you share some details on how the nRF and the imx6ull are connected. Are they connected directly via UART, or do you use some UART -> USB bridge? A Voltage level shifter? Anything else in between, or is it just pcb traces carrying the UART signal?

    Best regards,

    Edvin

  • Hi Edvin,

    Thanks for discussing with the Thread team. We shall compile our response for all your queries and get back as quickly as possible.

Related