How do I disable RTT log notifications on spi peripherals?

When I use the spi of nRF5340 to read the data of ADS1299, I find that whenever I use J-LINK to read the RTT LOG, there will be an error (spi_nrfx_spim: Timeout waiting for transfer complete). I can't find the related log in the nrfx_spim.c file again. Once the RTT LOG is turned off, the SPI timing is exactly correct. Whether to print a large number of logs also consumes CPU thread time. Note: I have turned off the TFM while watching the tutorial

I hope to get your help. Thank you
SOK

Parents
  • Hi SOK

    It sounds a bit odd that logging on its own would cause issues for the SPI communication. 

    How often do you try to read the ADS1299? 

    You should be able to disable logging for the SPI driver by adding the following line to your project configuration:

    CONFIG_SPI_LOG_LEVEL_OFF=y

    If you are still having issues could you include your log in the case? 
    If you do please use the Insert -> Code feature in devzone to add larger blocks of text. 

    Best regards
    Torbjørn

  • Thank you very much for your reply, I finally opened a new thread dedicated to reading 1299 data through spi, and then there is no problem. Previously read in an interrupt of gpiote, the logic analyzer found that spi was supposed to read 27 bytes of data, but the sck timing was only 10 bytes. My guess is that the priority of the interrupt is not higher than the priority of other threads in the BT stack, so the timeout error caused by the interruption.

  • Hi SOK

    It is quite limited what you can do in an interrupt handler directly, and this includes most sensor drivers which you can not access directly from an interrupt. 

    The quickest way to work around this is to use a work item, that you push to the system workqueue. Then you can schedule the sensor access from the GPIOTE interrupt, but have the actual code run from thread context. 

    There is more information about this in the devacademy beginner and intermediary courses, as well as the workqueue thread documentation

    Best regards
    Torbjørn

Reply
  • Hi SOK

    It is quite limited what you can do in an interrupt handler directly, and this includes most sensor drivers which you can not access directly from an interrupt. 

    The quickest way to work around this is to use a work item, that you push to the system workqueue. Then you can schedule the sensor access from the GPIOTE interrupt, but have the actual code run from thread context. 

    There is more information about this in the devacademy beginner and intermediary courses, as well as the workqueue thread documentation

    Best regards
    Torbjørn

Children
No Data
Related