Has anyone used the SEGGER J-Link SWO Viewer? I’ve not had any success with using it. My understanding is that it should allow the display of printf-like statements using am_util_debug_printf(…). I am running am_bsp_itm_printf_enable() to setup the ITM. I’m assuming that has been confirmed to work, but that’s just an assumption. So far, I’m not seeing anything from the J-Link SWO viewer.
Have a look at this thread “Success: Using Segger Embedded Studio with Artemis” in the “Feedback On Everything Artemis” section. Robin Hodgson has done some great work writing a document on how to do it. (Artemis for Segger Studio 1V6, be sure to get the 1V6 not the 1V5.) Be sure to do every single step. It worked for me, I am using the Segger j-link edu.
We are also discussing the SWO functionality here:
https://github.com/sparkfun/SparkFun_Ap … /issues/19
The solution we settle on there will trickle down to Arduino at some point
Thanks for linking those posts - I had not been aware of them before and they look helpful!
liquid.soulder:
We are also discussing the SWO functionality here:https://github.com/sparkfun/SparkFun_Ap … /issues/19
The solution we settle on there will trickle down to Arduino at some point
Thanks for linking those posts - I had not been aware of them before and they look helpful!
Thanks, that issue #19 discussion filled in most of the missing details I needed to get this working. I can now use am_util_debug_printf() over the SWO pin on the debug connector to the SEGGER JLinkSWOViewer on my Artemis Redboard. My assumption that the SWO pin was configured when I used am_bsp_debug_printf_enable() was part of the problem. To get this working I had to configure the SWO on pad 33. Then, I used am_bsp_itm_printf_enable() rather than am_bsp_debug_printf_enable(). Since am_bsp_debug_printf_enable() depends on g_ui32PrintInterface being set properly before internally calling am_bsp_itm_printf_enable(), I chose to call am_bsp_itm_printf_enable() explicitly. Note that am_bsp_itm_printf_enable() sets g_ui32PrintInterface = AM_BSP_PRINT_INFC_SWO. The existing BSP logic for setting up the SWO is a bit confusing, but I won’t get into that.
It would be nice if the SFE Artemis Hookup Guide include some documentation on setting up the SWO. On thing that could be updated to show that pad 33 is available for SWO is [RedboardArtemis Datasheet. Ditto for all the other Artemis boards.
Thanks again for the good info.](https://cdn.sparkfun.com/assets/learn_tutorials/9/2/5/RedBoardArtemis.pdf)
Thanks David - I was looking into this too until other things came up. Firstly I will let people know that some additional documentation is needed. Also I have merged the branch that improves access to ITM. Some notable facts:
-
Artemis Thing Plus got a default ITM_SWO pin definition for the in that is connected to the debug header
-
Default ITM/SWO baud rate is set to 2000 kHz (to best match with the options from the J-Link SWO Viewer program)
-
When boards do not have an obvious choice for ITM/SWO pin (e.g. there is not one exposed on the debug header) then the ‘am_bsp_itm_printf_enable’ function gets a new signature. This causes an error that will alert users that their board does not have a default and also allows then to pass in the desired pin number as well as the pin configuration to use.
VA3SU:
Have a look at this thread “Success: Using Segger Embedded Studio with Artemis” in the “Feedback On Everything Artemis” section. Robin Hodgson has done some great work writing a document on how to do it. (Artemis for Segger Studio 1V6, be sure to get the 1V6 not the 1V5.) Be sure to do every single step. It worked for me, I am using the Segger j-link edu.
VA3SU, I did read through that thread and Robin’s very good document. Since I’m currently going with the VS Code based IDE, I haven’t done anything with SES. I like a lot of it’s features, but I like the light weight, low cost (free!) VS Code solution. I also prefer that the VS Code editor fits my workflow better than the Eclipse based SES editor. I wasn’t familiar with SES’s ability to send printf to a debug terminal. That looks interesting. I’m curious how that functionality gets linked into the application. I guess SES has some library to link to? Robin’s document didn’t mention how that happens. I may try SES in the future, though.
davidmdj I’m a novice to put it lightly in this level of tool, the SES, but I like what I see so far. As far as printing to the debug terminal I changed the “am_util_stdio_printf” to just printf and it works… just with far less formatting options.
Everyone - the [BSPs are now updated with the correct pin definitions for the SWO pin on the debug header for all the boards. The default SWO baud rate is set to 2M (2000 kHz). This means that a) most examples from the apollo3_evb should now work and b) that in most cases you can just change ‘am_bsp_uart_printf_enable();’ to ‘am_bsp_itm_printf_enable();’ to use SWO printing.
When you are not in the SES environment you can use the J-Link SWO viewer tool to see the output.](GitHub - sparkfun/SparkFun_Apollo3_AmbiqSuite_BSPs: One-stop-shop for all your AmbiqSuite SDK board support package needs.)
I built my self a Segger J-Link to Sparkfun SWD cable adapter. If anyone would like one for them selves I can ship the bare pcb anywhere postage included for $5U.S. If you would like everything including cables and all connectors including the one to be soldered onto the Redboard the cost shipped anywhere is $15.
PM if interested.
Regards,
Kevin
Nice touch with the headers for your logic analyzer!
Thanks, the logic analyzer header came in handy almost immediately. While soldering the 0.050 connector I shorted the reset pin to ground.