After reading the viewtopic.php?f=171&t=53923 thread, I have some questions regarding mbed OS on Artemis Redboard, Redboard ATP, etc. I’m a little worried that users of those older boards are getting left behind in favor of the new “Dev Kit” hardware.
I have the Redboard and ATP. I have had good success developing with Ambiq Apollo SDK, VSCode, C/C++, and my J-Link debugger. I’m interested in the mbed OS because I’ve used it before, I can develop with C/C++, it has a slew of drivers ready to run. However, I have a lot of complaints about the development environment and the completely bloated design of the development architecture. I won’t go into those because it would take too long and I doubt that most users care.
With that said, here is my question:
Can Sparkfun add an example that generates the ELF and runs a debug session in J-Link to the dev kit tutorial?
I haven’t used mbed Studio in many, many months, so I don’t know if the current version can generate the ELF. I know the other option is the mbed CLI, but I prefer not to go that route.
I am working on the Mbed OS tutorial. I hadn’t thought about a debugging method for those boards and I will follow up with the engineering team on that.
That being said, it might be limited to the ArtemisDK due to the fact the Mbed OS utilizes the DAPLink firmware on the interface chip for debugging, which the other boards don’t have. However, I read some posts and it looks like you can use the custom targeting to debug with a J-link (again I would need to follow up with the engineering team, cause I don’t have that hardware).
Our engineer said that you should be able to debug with a J-Link programmer, since the other boards don’t have an interface chip with the DAPLink firmware.
To answer your question:
Can Sparkfun add an example that generates the ELF and runs a debug session in J-Link to the dev kit tutorial?
No, that doesn't seem very logical. The Artemis DK has the interface chip implemented, so that it doesn't need an additional programmer to program or debug the board. However, I may look into it for the other boards.
My question was not as precisely worded as it should have been. In the tutorial, there is a section at the end, [Build and Flashing other Artemis Boards. I was asking for more detail on the steps/process for generating other build files, specifically the ELF file, and sending to the Segger J-Link debugger. I don’t know if this is possible within Mbed Studio, etc.](Artemis Development on Arm® Mbed™ OS (Beta) - SparkFun Learn)
I’ll discuss this with the engineers, but I’m guessing no… setting this up in Mbed Studio will most likely be beyond the scope of the tutorial. We released the Artemis DK specifically to developers allow users to program and debug with Mbed OS; so we will at least provide debugging information specifically for that board.
Mbed OS documentation seems to indicate that it might be possible (if you want to dive down that rabbit hole):
The Mbed documentation seems to indicate that the .elf file can be built, but I’ve only seen instructions for using the CLI/GCC toolchain. In Mbed Studio, you might be able to generate it with the debug profile; however, Mbed Studio only allows me to select that profile for Mbed enabled hardware.
It is now 2/23/2022, I wish I have came here first before spending money on the red boards. Sparkfun needs to say up front what works with what instead of wasting customers time finding out the hard way, a fast way to lose customers. I just installed the Mbed fright mare, hardly worked 4 years ago, hasn’t gotten better. I’ll try the SDK, hope it works as in compile and program without five hours of screwing around.
Santa_Impersonator:
I’ll discuss this with the engineers, but I’m guessing no… setting this up in Mbed Studio will most likely be beyond the scope of the tutorial. We released the Artemis DK specifically to developers allow users to program and debug with Mbed OS; so we will at least provide debugging information specifically for that board.
Mbed OS documentation seems to indicate that it might be possible (if you want to dive down that rabbit hole):
The Mbed documentation seems to indicate that the .elf file can be built, but I’ve only seen instructions for using the CLI/GCC toolchain. In Mbed Studio, you might be able to generate it with the debug profile; however, Mbed Studio only allows me to select that profile for Mbed enabled hardware.
" allow users to program and debug with Mbed OS"
OK, ordered the ‘Artemis Development Kit’ but why didn’t you put the 10 pin headers on the board? It is a DK designed for DEBUGGING so what idiot made the decision to leave off J2 & J3? :?
Sorry for the delay in my response, I only pop on the forums when I have some free time. In regards to your last post, on the Artmis DK board, those headers are here (color coded by target):
The details for the TGT JTAG pins are in the Artemis Module section of the Hardware Overview:
The details for the INTFC JTAG pins are in the Interface Chip section of the Hardware Overview:
Additionally, (if I’m not mistaken) users should be able to debug the Artemis module without having to use the JTAG pins by using the interface chip to debug their code. It’s been a few years since that tutorial was written up, so forgive me if I mixed up the information.
To answer the previous post, we don’t provide the debugging information on the other Artemis boards (for MBed OS) because our partnership with MBed was specific to the Artemis DK (after the release of the other board versions). We created/designed that board for the partnership, so it could be available on MBed OS… which required adding the interface chip (not on the other boards).
i.e. The other boards don’t have the interface chip, which is required before they can be added to MBed OS… no interface chip = no joy
If you’d like to debug the other boards with a Segger programmer, please refer to this guide on ARM programming:
This is a more general guide and won’t have step-by-step instructions. It’s purposely written for users to get started with ARM programming and direct them to necessary resources (if they’d like to go down the “rabbit hole”), since not all ARM microcontrollers are specific to a single platform/IDE/etc.
no joy