Hello Circuit Dojo Community,

Is there anyone or any team here utilizing Zephyr’s thread_analyzer debugging module or feature, in a way that permits redirecting its output from console UART to another arbitrary UART? Or to a memory location which application code can access?

In a Zephyr 2.6.0 based project, which also depends on parts of Nordic Semi sdk-nrf 1.6.1 I have enabled thread_analyzer with the following related symbols assigned in my app’s prj.conf file:

32 ## 2021-11-11 - Zephyr thread analyzer work:
33 CONFIG_THREAD_ANALYZER=y
34 CONFIG_THREAD_ANALYZER_USE_PRINTK=y
35 CONFIG_THREAD_ANALYZER_AUTO=n
36 CONFIG_THREAD_NAME=y
37 #CONFIG_THREAD_ANALYZER_AUTO_INTERVAL=5

At first try I observed thread statistics to print every five seconds on the “Zephyr chosen” UART, uart0 on the Sparkfun Thing Plus nRF9160 dev board I am using. By setting CONFIG_THREAD_ANALYZER_AUTO to ‘n’ I can now print thread statistics just on demand, manually, through a CLI facility I’m building. But the CLI by design communicates on an alternate UART. (Arm Cortex-M33 has four UART peripherals). I would like the thread_analyzer messages to be directable to that non-console UART. I’m having trouble finding a Zephyr oriented, correct way to do this.

No one appears to have posted a question like this at Nordic Devzone. I also have cast the net with Google searches, but to no avail so far. Is there a specific chapter or section in Zephyr Project documentation that could answer this?

Reading through Zephyr’s built-in logging and tracing documentation, but so far not finding anything seemingly related to this present need and question.

  • Ted

    tedhavelka66 may be a good question for Devzone. You may have to edit the thread analyzer code itself to pull a different UART instead of the default console. You can re-map the console UART but that will re-map everything.

      Good morning Jared,

      Thank you for your reply. I was looking into re-mapping the console UART, and your comment matches what I was finding in Zephyr’s code base: I would be re-mapping everything by changing the console UART. That poses consequences which would be more harmful than helpful!

      I think I may have found a solution. I had already gotten a clunky “arbitrary UART” module up and running a few weeks ago. This module uses Zephyr 2.6.0 uart_poll_in() and uart_poll_out() API routines, available if I ‘#include <drivers/uar.h>’ in given Zephyr app. With that in place, a day or two ago I was able to craft a callback routine to Zephyr thread_analyzer API routine named thread_analyzer_run(). This routine expects a pointer to a function that takes as its sole parameter, a pointer to a Zephyr struct of type thread_analyzer_info.

      I’ll try to share the full solution. The basic idea is that, once I implement a function that understands how to read a pointer to thread_analyzer_info structure, I can then send the information string and numeric to any UART or other buffer-able comm’s link such as an I2C bus instance. I’m probably not using Zephyr’s facilities efficiently, but what is the programmers’ saying? “Make it work, make it faster, make it right?”

      • Ted

      Related to use of Zephyr’s thread_analyzer API, I also needed to add a stanza to my app’s CMakeLists.txt file:

      # 2021-11-11 - trying to bring in thread_analyzer.h:
include_directories(../zephyr/include/debug)

      This surprised me a little, that this cmake based build project did not already have this in its known paths. I’d enabled three or four Kconfig symbols related to Zehphyr thread analysis, every symbol which was described as needed in a Nordic Devzone post from a year or two ago. I’ll need to track down that post. The developer there had replied that that solution was sufficient and working for him. Was not a much older release of Zephyr and Nordic’s SDK than Zephyr RTOS 2.6.0 and sdk-nrf v1.6.1.

      • Ted
      Terms and Conditions | Privacy Policy