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

UART framing error after NVIC softreset

Hi all

Our application, built on the NRF51822 Rev. 3 and the SoftDevice S130 V1.0.0, uses the UART0 with 115'200 baud, 8N1, to communicate with another controller/PC. Hardware flow control is disabled. The SoftDevice is already initialized (with RC oscillator calibrated every 4s as LFCLK source) when we initialize the UART interface.

When our application receives a specific command over UART from the other controller, our application performs a softreset by calling the function NVIC_SystemReset(). Afterwards the chip starts-up normally and initializes first the SD and second the UART interface.

Sometimes it happens that after the softreset the communication doesn't work anymore. In this error case, the UART signals a framing error (ERRORSRC = 0x04) for every received command. The UART registers are still set correctly and the other controller sends still correct commands.

I also tried the function sd_nvic_SystemReset() instead of NVIC_SystemReset(), but it didn't solve the problem.

This problem doesn't occur with one of the following modifications:

  • either I disable the SoftDevice with sd_softdevice_disable() before calling NVIC_SystemReset(),
  • or I choose the LF crystal as LFCLK source at the SoftDevice initialization.

It looks to me like an issue with uninitialized variables in the SoftDevice in combination with the 4s calibration of the LF RC oscillator. Could this be an issue in the SoftDevice? Or must the SoftDevice always be disabled before a softreset?

Kind regards

Parents
  • When you said that there is a framing error, then it means that the device that is sending commands over serial port got out of sync. Is it using hardware flow control on UART?

    How does the peer device know that nRF chip booted up from its reset, and all its UART configuration re-initialized before sending new commands?

    I have a couple of theories of why disabling softdevice or using XTAL clock works for you. But before going that way, we have to make sure that your peer device is waiting enough time for the chip to come to a stable state. Please let me know how your peer device waits?

  • I will now try it with the synthesized LFCLK. In the uart event handler the p_event->evt_type is APP_UART_TX_EMPTY. But when I try the same software on the nRF52-DK, then p_event->evt_type wont be APP_UART_TX_EMPTY and I then the CPU wont reset.

Reply Children
No Data
Related