Success: Using Segger Embedded Studio with Artemis

Development Boards Artemis
1

Hi all, I have been using Segger Embedded Studio with my Artemis boards now for over a month. In short, it works quite well. Unlike Keil and IAR, SES is free for non-commercial use without the crippling code-size limitations of the free version available from Keil and IAR. SES is based on GCC, so the code quality is excellent. But the whole reason for using SES was to get native support for full hardware debugging, as detailed here viewtopic.php?f=171&t=50960.

If you replicate what I have done, you will be able to write Artemis software in C or C++ with full access to the Ambiq Suite libraries. The best feature is that attaching a J-Link EDU or J-Link Mini will allow you to reflash firmware, examine call stacks, set breakpoints, watch variables, and do everything that a hardware debugger enables you to do, all of it integrated natively into the SES IDE.

I have found it hugely useful to use the SES symbolic directories to include the Ambiq Suite sources in every project. Doing so enables you to use the SES editor to walk through the Ambiq sources, or jump directly to where one of your Ambiq HAL calls is defined so you can see how it works. You can even single step through the libraries or set breakpoints inside them just like any other software you write. And of course, when the program you are writing crashes into the ARM hardfault handler for the umpteenth time, the hardware debugger lets you work backwards through the callstack to find out why.

There is also support for the Segger IO debug mechanisms so that you can use printf() to send data to a terminal window hosted by the debugger. The IO goes over the debug connection meaning that the processor’s entire hardware resources are still available to your application.

I am happy with how it all turned out. However, I will say that it was not the most intuitive process for me to get everything working, and it is quite likely that some things I did were non-optimal due to me having to learn SES as I went. If you want to give it a try yourself, I have attached a document that describes how you can replicate my setup. This process has been tested by a couple of volunteers, so it should be mainly debugged at this point. Feel free to send me a reply or a PM if you have a better way of doing this stuff and I will do my best to keep the doc updated. I am hoping that the document will come through as an attachment. It is a zipped PDF.

Artemis for Segger Studio 1V5.zip (338 KB)

2

Thanks so much for posting this Robin! Will be trying this weekend!

3

Just finished flashing the hello world using the Segger Embedded Studio thanks to your instructions Robin. Thanks so much for posting this! I had purchased the their J-link edu from your comment about it a few weeks ago and built up an adapter to connect to the Red board. Really nice having a real hardware debugger!

Regards,

Kevin

4

Excellent! Glad to hear it.

5

It has been brought to my attention that I introduced a couple of mistakes into the 1V5 doc. Here is the 1V6 doc, which fixes them.

Artemis for Segger Studio 1V6.pdf (371 KB)

6

I’ve noticed that if I program my redboard to blink an LED it works fine while the Segger debugger is connected but not if the debugger is disconnected from the redboard. I’m sure it’s a setting somewhere but… Can’t find anything.

How do I make it stand alone?

Regards,

Kevin

7

Make sure that your debug sessions have not accidentally overwritten the Sparkfun bootloader. This could happen if you ever wrote flash below 0x00010000, for example if you missed the step about telling the linker to create the executable starting at address 0x00010000. The debugger can install your program anywhere and get it running, but the bootloader insists that it start at 0x00010000.

One way to test that the bootloader is working is to build and download any Arduino sketch. If the sketch does not download, it is probably because the Sparkfun bootloader is gone. If so, there are instructions on the Sparkfun site on how to reinstall the bootloader. They work, because I have had to do it :oops:

8

Thanks Robin. One great part about this fix is that I was able to restore the bootloader from within the Arduino App. Just pick Ambiq Secure bootloader and then program bootloader.

Regards,

Kevin

9

Worked like a charm for Hello World but…

Tried two different Edge2 projects that I have previously compiled and loaded with GCC. One that blinks the led’s, and the amdtpc Ambiq client app. I would love to be able to debug the many messages so that I can complete my Android app to talk back and forth with these boards. As I was adding include paths and re-building, I kept running into this error and have spent hours playing with it without knowing why it’s occurring.

expected identifier or ‘(’ before numeric constant

It shows as a build error with a red X but does not jump to a line or a file when the error is clicked on as other errors do. Googling seems to imply a duplicate definition somewher or something like that. ANY IDEAS???

Here is the entire output:

Building ‘Test’ from solution ‘Test’ in configuration ‘Debug’

‘Output/Test Debug/Obj/SEGGER_RTT.o’ is up to date

‘Output/Test Debug/Obj/SEGGER_RTT_Syscalls_SES.o’ is up to date

Output/Test Debug/Obj/ble_freertos_amdtps.o does not exist.

‘Output/Test Debug/Obj/Cortex_M_Startup.o’ is up to date

Compiling ‘ble_freertos_amdtps.c’

“C:/Program Files/SEGGER/SEGGER Embedded Studio for ARM 4.30c/gcc/arm-none-eabi/bin/cc1” -fmessage-length=0 -fno-diagnostics-show-caret -mcpu=cortex-m3 -mlittle-endian -mfloat-abi=soft -mthumb -mtp=soft -munaligned-access -nostdinc “-isystemC:/Program Files/SEGGER/SEGGER Embedded Studio for ARM 4.30c/include” “-isystemC:/Users/kerry/AppData/Local/SEGGER/SEGGER Embedded Studio/v3/packages/include” -isystem…/…/mcu/apollo3 -isystem…/…/CMSIS/ARM/INCLUDE -isystem…/…/boards_sfe/edge2/bsp -isystem…/…/devices -isystem…/…/utils -isystem…/…/third_party/FreeRTOSv10.1.1/Source/include -isystem…/…/boards_sfe/edge2/examples/ble_freertos_amdtpc/src -isystem…/…/third_party/FreeRTOSv10.1.1/Source/portable/GCC/ARM_CM4F -ISEGGER -D__SIZEOF_WCHAR_T=4 -D__ARM_ARCH_7M__ -D__SES_ARM -D__HEAP_SIZE__=1024 -D__SES_VERSION=43003 -D__SEGGER_LINKER -DDEBUG -MD “C:/Users/kerry/Documents/AmbiqSuite-Rel2.2.0/SEGGER Embedded Studio for ARM Projects/Test/Output/Test Debug/Obj/ble_freertos_amdtps.d” -MQ “Output/Test Debug/Obj/ble_freertos_amdtps.o” -quiet -std=gnu99 -g3 -gpubnames -fomit-frame-pointer -fno-dwarf2-cfi-asm -fno-builtin -ffunction-sections -fdata-sections -fshort-enums -fno-common C:\Users\kerry\Documents\AmbiqSuite-Rel2.2.0\boards_sfe\edge2\examples\ble_freertos_amdtps\src\ble_freertos_amdtps.c -o “C:/Users/kerry/Documents/AmbiqSuite-Rel2.2.0/SEGGER Embedded Studio for ARM Projects/Test/Output/Test Debug/Obj/ble_freertos_amdtps.asm”

expected identifier or ‘(’ before numeric constant

‘Output/Test Debug/Obj/HardFaultHandler.o’ is up to date

‘Output/Test Debug/Obj/SEGGER_HardFaultHandler.o’ is up to date

‘Output/Test Debug/Obj/SEGGER_THUMB_Startup.o’ is up to date

Build failed

I Loaded main .c file, built it and started adding include directories from Project/Options/Common/Preprocessor/System Include Directories as each “can’t find file error” occurred. Is there a better or workable way to build these files that works? Obviously my first time at this but if I have the prob., someone else probably will.

My goal is to get the amdtp app to work with an android app as the esp32 does so well … for IOT.

Thanks for reading…hope someone knows what is going on.

10

I think you missed a couple steps from the document. For example, your compile command does not define the processor type or the package type. Inside your compile output, I see this:

-DDEBUG -MD

After building one of my own project files just to see the command line, I see that my command line has some differences:

-D_DEBUG -DAM_PACKAGE_BGA "-DAM_PART_APOLLO3 " -MD

There are three problems in that one section of your command line. You can’t define “DEBUG” because that will cause a name collision with a badly chosen name of the struct field inside the Ambiq HAL. You also need to define the processor as being an Apollo3 and the package as being the BGA package. There may be more problems than that - I didn’t look past that.

The important point is that if you continue reading the very next sections of the Segger doc I posted, it will tell you how to fix the problems above.

11

Hmm. Looking at my command line showed me that I had a trailing space when I defined AM_PART_APOLLO3 in Segger Studio, which is why the system quoted it all with a space at the end. Fortunately, that ends up being completely harmless. But I fixed it anyway, and now I get:

-D_DEBUG -DAM_PACKAGE_BGA -DAM_PART_APOLLO3 -MD

If my crappy memory is right, the specific error you are seeing is due to the define of DEBUG via -DDEBUG. This defines a preprocessor symbol DEBUG to have no textual replacement. Sadly, there is a struct field inside the Ambiq HAL called DEBUG (boo: all upper case, so it looks just like a preprocessor symbol). Your -DDEBUG causes the name of that field (DEBUG) to vanish and the compiler gets annoyed when it is expecting to see a name and finds what follows the name instead.

12

Robin - this is excellent. Thanks.

13

Indeed this is excellent!

14

One other cool thing about putting in the time to learn Segger Embedded Studio is that they also have a version of Embedded Studio that supports RISC-V. I tried that out on a SparkFun Red-V board and it was flashing/running /hardware-debugging in short order.

15

Geat information!

16

Thanks Robin! Everything up and running (after finding the 1v6 update :oops: ). :smiley:

17

Excellent! I am glad to hear that.

Segger Studio has been working really well for me. The only downside is that it helps me make my software ever more complicated :slight_smile:

18

I am new to the Spark Fun Thing Plus - Artemis board. I want to use my Segger J-Link device with it. I was reviewing the schematic drawings of the Thing Plus and the SWD interface depicted is confusing to me. Does the Thing Plus use the conventional SWD pin layout?

I expect this (SWD on left side of schematic): https://cdn.shopify.com/s/files/1/0245/ … 1486589973

Look at the “SWD Program/Debug Interface” section of the Thing Plus schematic: https://cdn.sparkfun.com/assets/6/f/0/5 … ematic.pdf

What?

If it’s the same, what is the purpose of defining the pins out of order? If it’s different, why?

Thank you!

19

The two boards use different silicon debug interfaces. The Thing Plus uses SWD and the other board uses JTAG. To oversimplify a bit, you can consider SWD as being a subset of JTAG, as if it were “JTAG Lite”. The Artemis chip has SWD support, so the connector is wired up with the SWD names for the signals. Other chips may support the full JTAG interface, so their debug connector will be wired up using the JTAG names.

The important thing is that the J-Link debugger knows how to speak both protocols. When you configure the debugger in your build environment and explain what processor you are using, the IDE will arrange to use the correct interface for the chip you are debugging. It’s all pretty slick, if you ask me.

20

I answered my own questions.

  1. The SWD pin layout on the Spark Fun Thing Plus is the standard SWD pin layout

  2. The reasoning for the pin layout to be enumerated out of order in the schematic is due to convention (i.e. reset at the top)