• State Verified Answer
  • Replies 2 replies
  • Subscribers 65 subscribers
  • Views 98 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 328958
Options

LOG module thread priority

puz_md

Hi, I read somewhere that the LOG module works differently from printk() and uses a separate thread or so. But I couldn't find any information which priority this thread uses (or in which context the LOG module's handler runs).

I have strange situations where LOG_INF() messages don't work anymore, even though I call k_msleep() in the main thread. Any ideas? It might also be realted to enabling apairing/bonding features in proj.conf, I'm still researching the reason. But it would help understanding how the control flow of the LOG module works...

Thanks,
Michael

PS: I'm currently using RTT for debug output, if it is important.

Parents
  • +1

    Hi Michael,

    The logger processing thread is used when using it in deferred mode (CONFIG_LOG_MODE_DEFERRED=y - selected by default), and the priority of this thread is set to the lowest application priority (K_LOWEST_APPLICATION_THREAD_PRIO) unless the app defines a custom LOG_PROCESS_THREAD_CUSTOM_PRIORITY value.

    I have strange situations where LOG_INF() messages don't work anymore, even though I call k_msleep() in the main thread. Any ideas? It might also be realted to enabling apairing/bonding features in proj.conf, I'm still researching the reason. But it would help understanding how the control flow of the LOG module works...

    This suggests that the idle and logger thread are never allowed to run. Enabling the Thread analyzer may help you find out which thread is blocking your logger. You will need to select LOG_MODE_IMMEDIATE, or change the priority of the logger thread through  CONFIG_LOG_PROCESS_THREAD_CUSTOM_PRIORITY to get the log output from the thread analyzer.

    Best regards,

    Vidar

Reply
  • +1

    Hi Michael,

    The logger processing thread is used when using it in deferred mode (CONFIG_LOG_MODE_DEFERRED=y - selected by default), and the priority of this thread is set to the lowest application priority (K_LOWEST_APPLICATION_THREAD_PRIO) unless the app defines a custom LOG_PROCESS_THREAD_CUSTOM_PRIORITY value.

    I have strange situations where LOG_INF() messages don't work anymore, even though I call k_msleep() in the main thread. Any ideas? It might also be realted to enabling apairing/bonding features in proj.conf, I'm still researching the reason. But it would help understanding how the control flow of the LOG module works...

    This suggests that the idle and logger thread are never allowed to run. Enabling the Thread analyzer may help you find out which thread is blocking your logger. You will need to select LOG_MODE_IMMEDIATE, or change the priority of the logger thread through  CONFIG_LOG_PROCESS_THREAD_CUSTOM_PRIORITY to get the log output from the thread analyzer.

    Best regards,

    Vidar

Children
Related