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

UART Logging Backend hangs in nrf_bootloader_app_start

Hi Community,

I want to use the UART Logging backend in my bootloader. Whenever I want to start the actual application via nrf_bootloader_app_start(), the bootloader hangs in nrf_fprintf_buffer_flush in a while loop.

    while (m_async_mode && (m_xfer_done == false))
    {

    }

Can someone help solving this issue?

Best regards,

Nico

  • Hi, I found the same issue here. If NRF_LOG_DEFERRED is set to 1 the backend in `nrf_log_backend_uart.c` uses interrupts to set `m_xfer_done` to true once the UART transfer is done, this is done via the even handler `uart_evt_handler` in that file.

    However, in `nrf_bootloader_app_start` the code is disabling the interrupts and calling NRF_LOG_FLUSH which then hangs because the `uart_evt_handler` is never called (the interrupt is probably pending).

    This is a bug in the SDK code.

    One option is to set NRF_LOG_DEFERRED to 0 as mentioned here, this will not use the event handler/interrupts. This doesn't require any code changes.

    The other option would be for nordic to fix the SDK code. I think that one way to fix this in this case would be to call the log messages and flush before we disable the interrupts. Another option is to fix the flush logic to not rely on the interrupt being attended since it is doing a busy loop anyway. In `nrf_log_backend_uart.c`, function serial_tx there's this while() loop waiting for the event handler to be done. I think that if your message is too long you need several interrupts to trigger before you get a call to the event handler, so maybe forcing an interrupt call (just calling directly the equivalent function from the loop body) would work, but this is not exposed at all in the driver.

    Should we create a support case for this?

  • I still think that NRF_LOG_FLUSH in the nrf_bootloader_app_start should be removed. If interrupts are disabled, it will hang.

    Didn't see a bug fix in SDK 17.

Related