This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Problems with UARTE on nRF52832

Hi. We are using nRF52832 and we have problem with UARTE. SoftDevice version - S132 5.0.0, SDK version - 14.2.0.
Our application uses nRF and Mbed Serial to communicate with the GSM module using UART protocol with RTS/CTS flow control and sometimes reception errors occur, such as missing or incorrect bytes. Worth noticing: this errors occur only when there is BLE scan running at same time.
With digital analyzer we saw that there is no interference on pins and data transmits to nRF correctly, but sometimes nRF doesn't set RTS pin high after receiving next byte and apparently doesn't generate ENDRX event, which causes data corruption:

Our first hypothesis was that UART interruppt handling takes too much time due to the high priority interrupts from SoftDevice. So we modified implementation of Mbed Serial to work with a larger DMA buffer (DMA buffer is now flushed after a certain timeout after receiving last byte from the modem. The number of bytes received is counted using PPI and TIMER). But reception errors still occur. After connecting RXRDY event to pin toggle task, we can see that sometimes nRF doesn't generate RXRDY events properly:

Do you have any idea why this could happen?

Parents Reply Children
  • In the current implementation, the STARTRX task is triggered before the command is sent to the modem, so reception is guaranteed not to start while receiving a response. The STOPRX task is also triggered some time after receiving a full response from the modem.

  • Then the other alternative is that the baud rate is way off. A bit difficult to see from the trace, but looks like 28800baud?

    In any case, I think using libuarte is the way to go.

  • Then the other alternative is that the baud rate is way off. A bit difficult to see from the trace, but looks like 28800baud?

    I made sure that the nRF and modem are using the same baud rate (38400). Also tried different baud rates in the range from 9600 to 115200.

  • From the screenshot you sent earlier it looks like one byte (I assume that is with 1start bit and 1 stop bit) take about 35.02us = ~28.600baud. The closest then I assume would be 28.800baud and starting hfclk before reception. If that still fails, then you would need to add some debugging to make sure that you don't by accident start rx in the middle of a transaction by adding some pin toggling or similar on a spare gpio (e.g. maybe the rx start is delayed for instance if the softdevice block the application code for a period of time). Also check if serial library may start rx through the uart interrupt handler.

    Update:

    After looking at your initial screenshot I can see that the timing between RXRDY events are far bigger than the timing between UART bytes. So there must be a mismatch in baudrate here.

    I do not understand what is causing the seemingly large delay from first UART byte to GPIOTE toggling indicating RXRDY. If there is a PPI channel from RXRDY to GPIOTE toggling I would expect them to be much closer in time.

    Best regards,
    Kenneth

Related