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

UART printf stops in spi_event_handler function

Hi,

Hope this is not a duplicate post. I am using nRF52832 and SDK Ver 11 and am facing the following issue:

After configuring the UART and SPI, I put a string e.g. "start..." in the printf function. Immediately after that the SPI function and then spi_event_handler are called. I put a long delay in the SPI interrupt handler function to check the performance of the UART along with SPI when they are working in high speed. Before entering the SPI handler function only the first three characters are sent by UART. The rest of the characters are sent after the CPU has executed the long delay and returns from the handler function.

Questions:

1- The printf function is non-blocking, right? (I have the UART handler function too)

2- Is this a correct performance that sending the bytes via UART is terminated when the CPU is stuck in the SPI interrupt handler function? Or I am doing something wrong in my code?

Parents
  • Printf uses UART and depending on what drivers you are using it can be blocking or non blocking. In SDK6, using simple_uart.c API in retarget.c made printf blocking because then UART did not use any interrupts and waited until it sends/receives a byte.

    But at later SDKs UART drivers and libraries became asynchronous using their interrupt handlers.

    Since you are using SDK11 so you are using app_uart with fifo. Then the UART irq priority will be defined in the nrf_drv_config.h file

    #define UART0_CONFIG_IRQ_PRIORITY APP_IRQ_PRIORITY_LOW
    

    If SPI drivers are using APP_IRQ_PRIORITY_HIGH then you will be able to write to fifo but the actual write to uart will be delayed as data is written synchronously byte by byte through the ISR.

Reply Children
No Data
Related