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?

  • The sensor has a STI32F100 with a 12MHz Crystal on it. The crystal has 10ppm accuracy. I tested now the same application with RC LFCLK on the nRF52-DK and its working. So it should work with the RC LFCLK.

    With the Rigado board I tested all LFCK's and none of this worked. And with the nRF52-DK all of these worked...

Reply Children
No Data
Related