Edge, SEGGER JLink and printf

I’m a Mac user trying to get the Edge to work using JLink via USB. The first problem was how to get the 1.27mm 10 pin JTAG header to mate with the 2.54mm 20 pin JLink. I ordered the tiny 10 pin JTAG headers from Sparkfun, soldered the headers (using a microscope), and then tried to wire it with a breadboard - no go. So I ordered the $30 SEGGER adapter from Mouser for exactly that purpose, and hurray, it works.

I ignored all the secure bootloader stuff and just downloaded the example1 bin file provided in the gcc directory of the SparkFun Edge board code. JLinkExe and JFlashlite both load the bin fine at the 0xC000 location. The program appears to run, the LEDs light up, and they go out when the button next to them is pressed, just as the program code specifies. Then the press of reset and it starts starts all over.

Note my only connection is via USB → JLink → $30 adapter → 10 pin JTAG header → Edge. I connect using SWD.

I can’t get the printf statements to display. I tried the SWOVIEW command of JLinkExe without success. I then tried the JLinkSWOViewer program and I don’t know what the target device name is so it doesn’t work. The actual printf function name is am_util_stdio_printf. Is that UART only output? I don’t have a UART to USB converter - I’d really prefer to send debug info out the SWO port. Is that possible? How do I accomplish that?

Hi Don,

The first thing I did was to ensure that SWO was in fact broken out on the JTAG header, which it is. (Pin 6)

Then I checked that pad 33 (as indicated in the picture) does have SWO capability – it does!

https://cdn.sparkfun.com/assets/learn_t … apping.pdf

The above items were just simple sanity checks b/c I had a suspicion about what the problem might be…

the ‘am_util_stdio_printf’ function is a higher-level API that redirects the print to board-specific print interfaces. Depending on what combination of board (BSP) and example that you are using it may be:

a. defaulting to UART output (if using the Edge BSP and an example that we provided with the Edge BSP_

b defaulting to SWO ouput on the wrong pin (b/c we have rarely if ever used SWO and the pin definition in the Edge BSP may be incorrect)

For an example of this let’s look at ‘main.c’ in the ‘example1_edge_test’ project under the Edge BSP’s example directory. Inspecting the ‘boardSetup’ function we see the lines:

    // Initialize the printf interface for ITM/SWO output.
    am_bsp_uart_printf_enable(); // Enable UART - will set debug output to UART
    //am_bsp_itm_printf_enable(); // Redirect debug output to SWO

Typically we use the uart flavor, but if we inspect the swo flavor it leads to a function in the Edge’s BSP ‘am_bsp.c’ file. Among other things I see a peripheral being initialized (good) and a pin being configured (also good). Checking out ‘AM_BSP_GPIO_ITM_SWO’ and ‘g_AM_BSP_GPIO_ITM_SWO’ they seem to be properly configured as well.

So (fingers crossed) I hope that all you need to do to get your SWO working is to choose ‘am_bsp_itm_printf_enable()’ instead of the uart variety.

While we’re on the topic there’s also a wild ‘am_bsp_debug_printf_enable()’ variety that chooses your print interface for you based on the value of ‘g_ui32PrintInterface’ – so just beware all the different ways to get to the same place.

If you enable itm and it still doesn’t work try looking for a proper example from the Apollo3 EVB board – Ambiq prefers to use itm.

No joy using SWO. I made the source code changes suggested. I spent several hours trying various combinations of software and came to the conclusion that the SWO data just isn’t making it to the J-Link. There are a variety of pin combinations for the SWD interfaces - chip pad 33 seems to be the one the Ambiq software expects to be SWO. I have no way of verifying that is the case, so I went to plan B: Google.

I came away with the insight that I doubt anybody actually uses the SWD SWO output pin for Cortex-M4 development. Instead the SEGGER JLink RTT protocol appears to be what is most used. The protocol works without the SWO data line - it just uses the standard SWD clock and IO pins. RTT contains a variety of sophisticated features. A simple download of the RTT target C source from Github and adding a couple of files to the Makefile is all that is necessary, and bingo, I can now see debug output using the JLink RTT Viewer app which comes in GUI flavors for Mac and LINUX as well as Windows. Yay!

So my problem is solved for getting debug output from my app built using gcc. I hope this post helps others who don’t plan to use Arduino with the Ambiq Apollo3 chips to save a few hours. Thank you liquid.solder for looking into my issue and providing a detailed response.

Awesome Don, thanks for sharing what you found out with the rest of us!