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

Crash in nrf_log UART backend (NRF_ERROR_BUSY)

In a project using  NRF52832 and SDK V15.3, we're having random crashes which have been isolated to a NRF_ERROR_BUSY (17) in components/libraries/log/src/nrf_log_backend_uart.c:83 which means the actual error happens in nrf_drv_uart_tx(). In my testing this seems to (mostly?) happen in or right after a call to NRF_LOG_FLUSH_FINAL() which is a part of the shutdown procedure (the power to the MCU is turned off, so NRF_LOG_FLUSH_FINAL() is used to flush any outstanding logs), but QA testing reports crashes under various conditions not always related to the shutdown. The problem looks quite similar to this thread. I'm not using any flashlog or crashlog. The problem happens both with and without j-link connected.

Is there a recommended workaround available? Can I simply comment out the APP_ERROR_CHECK() in the SDK code that causes the error?

If more information is needed I'll be happy to do what I can to provide it. Thanks in advance.

Parents
  • Hi,

    It is a bit strange that this happens right after NRF_LOG_FLUSH_FINAL(), as this seems to uninit and then reinit the UART driver. The only thing I can think of is that the driver does not wait for transfers to finish during the uninit, which could possibly cause some issues if new transfers are started shortly afterwards. There are some fixes related to this in later versions of the driver. Have you considered migrating your project to the latest SDK version (17.0.2)? I would not recommend ignoring the error code, as this will leave the driver/m_xfer_done flag in the wrong state.

    How often do you get this error? 

    Can you post the call stack when you get this error?

    Do you have an example project or procedure that can be used to reproduce this issue?

    Best regards,
    Jørgen

Reply
  • Hi,

    It is a bit strange that this happens right after NRF_LOG_FLUSH_FINAL(), as this seems to uninit and then reinit the UART driver. The only thing I can think of is that the driver does not wait for transfers to finish during the uninit, which could possibly cause some issues if new transfers are started shortly afterwards. There are some fixes related to this in later versions of the driver. Have you considered migrating your project to the latest SDK version (17.0.2)? I would not recommend ignoring the error code, as this will leave the driver/m_xfer_done flag in the wrong state.

    How often do you get this error? 

    Can you post the call stack when you get this error?

    Do you have an example project or procedure that can be used to reproduce this issue?

    Best regards,
    Jørgen

Children
No Data
Related