Beware that this post is related to an SDK in maintenance mode
More Info: Consider nRF Connect SDK for new designs
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

how to use deferred NRF logging and twi manager

Hi,

When using the TWI manager you normally provide a callback function that is executed once the transaction has been completed. I'm using the NRF logger module to display the output from the device to my computer and don't know how I'm supposed to print the output of the transaction within the callback as the logger module is described as non-thread-safe (when I attempt to do so it throws and NRF BUSY error). I add a log in the main() function but I wouldn't know when the transaction had been completed.

As I'm using FreeRTOS should I include an NRF_LOG_FLUSH task and just rely on that?

Parents
  • The TWI callbacks are called from TWI interrupt context and calling NRF_LOG_FLUSH in that context is not correct as it is very time-consuming. 

    At which function does the NRF_BUSY error code is returned? could it be that the logger thread was running and was in the middle of the of processing the log buffer when the TWI ISR was called and left the logger module in a state where it would not accept any addition of logs to the buffer?  

    I have not seen the scenario above myself but would be possible. Could you give me your project so that i can test to see if that is the case?

  • Hi,

    I've since fixed the issue by moving to the deferred logging and flushing using a low priority FreeRTOS task. Is this the correct way to use the NRF Logger in conjunction with FreeRTOS? If not is there a FreeRTOS logger I should use instead?

  • George,

    George Sykes said:
    I've since fixed the issue by moving to the deferred logging and flushing using a low priority FreeRTOS task

     Since by default configUSE_TIME_SLICING is set to 0 in our examples, the scheduling becomes priority-based and cooperative. You might have already figured that out by now. Unless you choose the lowest priority for the logger task, there is always a chance that the logger task can starve other tasks for a reasonably long time. So choosing lowest priority for logger module makes good sense.

Reply
  • George,

    George Sykes said:
    I've since fixed the issue by moving to the deferred logging and flushing using a low priority FreeRTOS task

     Since by default configUSE_TIME_SLICING is set to 0 in our examples, the scheduling becomes priority-based and cooperative. You might have already figured that out by now. Unless you choose the lowest priority for the logger task, there is always a chance that the logger task can starve other tasks for a reasonably long time. So choosing lowest priority for logger module makes good sense.

Children
No Data
Related