SparkFun Forums 

Where electronics enthusiasts find answers.

What are we doing right with Artemis? What are we doing wrong? Let us know here!
#207949
If you are a TL;DR kind of person, the title is enough. If not, uncork a hazy IPA let's see how long you last:

As a starting point, let me say that I have been working with Atmel parts (now MicroChip) for over 20 years now. A long time ago, I got locked into Atmel's Studio development environment if only because it is a pain in the butt to learn ones all the time. But honestly, their Studio software development and debugging product is really good and gets better all the time. It's a great example of a product from a company that understands that you it is easiest to sell silicon when it is easy for developers to use. There are lots of silicon vendors out there who know that.

But now, I find myself entranced by the Apollo3 from a silicon perspective, but turned off from a development perspective. An Arduino environment is an awesome starting point. Arduino's main feature is that you can get running really really quickly because a single install takes care of hiding a myriad of details. Once installed, Arduino is great for running the built-in examples or for creating your own programs based on tweaking those examples. What Arduino is lousy for is developing a program that fills any substantial portion of the Apollo3's 1 meg of flash or 384K of RAM. Specifically, Serial.print debugging or blinking an LED only gets you so far until you end up with a stack problem or dangling pointer or race condition and you really, really wish you had a real debugger. I have found that the best way to write a complex Arduino library is to develop it in Studio using a real debugger, and port it back into the Arduino environment once it works.

I admit that real Apollo3 development environments with effective debuggers exist, but sadly, they cost real money. Keil's website says this morning that their cheapest solution is $1530 per year. I'm betting that kind of money is beyond the reach of the average Sparkfun customer. I know you can get a free version that is hobbled to 32K of output code, but again, if your program fits in 32K, just use an AVR. Or for overkill, use a Sparkfun board with a SAMD Cortex M processor. Either way, you can use Atmel Studio for a first-class development and debugging environment.

But still, the Apollo3 sings its siren song. Who can say no to all that memory and such spectacular power specs? Not me, but I'm a sucker for that kind of stuff.

What to do? I see that the Apollo documentation says that Eclipse and GDB was intended to be a development solution up until they hit some undisclosed problem and apparently gave up. But that was back in 2017, and two years have passed. I wondered if they made any progress. There is nothing on their website to indicate that they have, or even that they are still working on it.

With no other options, I thought that I would try the Eclipse/GDB route myself. I must point out that this is not my strong suit. At this point in my life, my goals involve using tools to make things, not making tools. But I dove in anyway.

I have since learned that Eclipse is configurable to the point of utter incomprehension. But thanks to google and to various people all over the world who know way more about this than me, I got Eclipse running in a fashion that generates binary files that I can use the Sparkfun bootloader to push onto my device. But all that just got me to a place where I could stare wistfully at the 'debug' icon and wish I could press it. Basically, I spent a bunch of time to create a different version of the Arduino development environment, albeit with a much better editor. But truthfully, I already had the Artemis working with Arduino in Visual Studio Code, so the much better editor already existed. [Apologies to all those out there that think that the only good editor is VIM/emacs/the-editor-you-binge-wrote-yourself-in-one-weekend, but you are wrong] To get back on track, the whole point of the Eclipse experiment was to be able to push that 'debug' button.

So I continued to work on that. I found a thing call a "Black Magic Probe" which claimed to debug all Cortex M cores. It contains its own GDB server and that sounded both cool and like one less thing I would have to worry about installing and configuring, so I got one. Days of googling later, and to my utter amazement, it is actually sort-of working. Now I can use my Eclipse environment to edit and build firmware, then I use the Sparkfun bootloader to push it onto the Artemis. And finally, I can actually click 'debug'. Assuming that the GDB is not in a snit from the previous session, my freshly downloaded program stops running at some random location. At that point, I can hover over variables and see their values. To my delight, I can watch CPU registers change as I single step code execution. Dang! That's what I'm talking about!! See the attached photo for proof.

But that's where the happiness ends. Problematically, what I can't do is make any changes to the flash. This means that the debugger can't flash a binary file or more importantly, set a breakpoint. So my new debug environment is tantalizingly there and hugely incomplete. It appears that to get full-on debugging capability, I would need to write a driver to go inside the black magic device that would describe all the low-level interactions required to work with an Apollo3. Sadly (for me), writing that driver requires an STM development environment. And almost certainly, a debugger to debug the driver. Amusingly enough, the Black Magic developers say that they can use a second Black Magic device as the debugger to debug their primary Black Magic device, but I'm finally starting to admit that maybe I bit off more than I can chew here.

So that's where I am: just like Tantalus in Greek mythology https://en.wikipedia.org/wiki/Tantalus, I see lots of tasty icons that appear in reach that I just can't click.

Sparkfun people, you must have connections into Ambiq. Are there any plans to create a real development environment? Are we on our own? Are there people out there in this community smart enough to write that Black Magic driver for an Apollo3? Or is that something that the Ambiq team could do? They obviously have some talented driver software people.

Finally, thanks for listening. I'm all ears for input on the topic.

P.S. I would be happy if someone pointed out that I was a complete moron for spending my time going down this rathole because solution XYZ already exists. Please, point me at it.

P.P.S. I'm tried hard not to sound like I was whining while spouting off above, but I won't be put off if you say that I was obviously and completely whining. I still want a development environment with a real debugger. All the cool kids have one.

P.P.P.S. I won't lie: I wish MicroChip would just buy Ambiq and add support for the Apollo parts to Studio. My life would be easy. C'mon MicroChip: Ambiq is still a private company. They must have some pretty good patents on their processes.
You do not have the required permissions to view the files attached to this post.
#207957
I too am quite interested in the Apollo3 for its superior performance including single precision floating point in combination with low power consumption and really low power sleep modes.

I'm in somewhat the same boat as Robin. I am more software oriented than hardware oriented. I have been using Eclipse for many years, so that's my preferred IDE. Of note, I'm a Mac user. (FWIW, I have a strong, mostly irrational aversion to Windows, Arduino and Python.)

I too got Eclipse to compile my C code for Artemis (both prior to FCC certification and after). But I took a different approach to flashing and debugging. I bought the Segger JLink Debug Probe with the 9 pin adaptor. My plan was to use the SWD pins for flashing and debugging. So I bought some of the 5x2 (1mm spacing) headers and soldered them onto the Sparkfun Edge and 3 of the Artemis boards I've bought (1 mm pitch hand soldering of headers is no fun). Then I used the Segger jlinkexe utility from the MacOS command line to flash the devices (flash to address 0xC000). I then went down a dead end attempting to use the SWO pin for printf type debugging. No joy. Then stumbled upon the Segger RTT protocol which uses the two primary SWD pins - SWDCLK and SWDIO - for both character stream input and output to/from my running program, in addition to their normal flashing and debugging duties. The Segger RTTViewer utility is just what the doctor ordered. I haven't yet attempted to make GDB Debugger Server work with it yet because of the warning from Ambiq.

My eventual goal is to use the Artemis module on a battery driven, custom 2 layer PCB without wasting electricity on a USB port, LEDs, etc. for various special uses. I plan to use FreeRTOS with mostly I2C and ADC interfaces. Longer term, I hope to figure out how to use BLE for flash updates so no SWD header will be required.

The information found on the Sparkfun web site in conjunction with the Edge board got me going. I used the gcc/make version of the source from Sparkfun, Ambiq and Arm. I found the file folder organization and the resulting complexities of the various Makefiles to be quite confusing, so I'm in the process of combining them so as to make much simpler Makefiles and better integration with Eclipse.

<rant> Unlike Robin, I hope Ambiq is not bought by Microchip. Having played with various Microchip chips and tools, I can tell you that my experience is that Microchip makes great little chips, but is brain dead when it comes to software developer tools. Their choice of Netbeans for their IDE a few years ago was a horrible choice, and is typical of their complete lack of understanding of developer tools. Their purchase of Atmel might change things for the better, but I wouldn't bet on it. </rant>

PS. I noticed a preliminary data sheet on the Ambiq web site for a new chip called the Apollo 3 Blue Plus which has a bit more capability, but importantly doubles the SRAM to 768K and doubles the flash to 2MB.
#207961
If I understand you right, you are saying that the Segger RTT protocol allows using the debugger interface pins for printf() debugging, and that you don't currently have a hardware debug option available to you.

I wish I could make the BlackMagic thing work. It would appear to be capable, but I think it needs someone smarter than me to write the appropriate driver for it. FWIW, the BlackMagic board also provides a secondary communication channel for printf debugging. I'm not saying I wouldn't use printf debugging, but it's a fact that when a variable is getting corrupted out of the blue, it's a more effective approach to just set a data write breakpoint on the corruption event and see exactly when it occurs and which instruction is responsible.
#207966
Yes, the Segger RTT protocol uses the two standard SWD pins (in addition to VDD and GND) for printf debugging. To implement it on Cortex M chips, Segger provides two small C files that you compile into your application. No drivers. Nothing special. And just SWD pins from the chip connected to the JLink debugger connected via USB to your computer.

I do understand the utility of hardware watch points. Segger sells those kind of tools for a few thousand dollars, but which is far outside my budget. However, because I'll be debugging FreeRTOS application code with several tasks, I think(hope) that the RTT_printf() approach will be sufficient.
#208005
I'm interested in this topic. I'm only a novice Eclipse user. I've used TI's Eclipse based Code Composer Studio to dev/build/debug on a TI CC3220SF-Launchxl. I'm not a huge fan, but it works fairly well. One thing I don't like is that TI pushes frequent updates. If it was up to me, I'd prefer to get VS Code running with a debugger. I'm a bit less experienced at this than you all. I also use VS Code with the Mbed CLI (command line) and some personal customization to develop libraries and applications. No debugger, only printf(). IMO, mbed has unnecessarily complicated my desired workflow. I won't go into all the details, but it has to do with the way they're trying to hide the whole build process behind their Python scripts. A lot of what they did is already available using make/Makefile's. Developers that don't pay attention will end up with a lot of duplicate folders for different applications (on of my priorities is code reuse). It can be done, but the documentation is not written with that in mind. On the positive side, I do like developing with C++. Mbed has excelled in that area.

I'm in agreement with the desire for a good debugger for development with the Artemis boards. Money is a factor for me, too. Otherwise, I wouldn't be looking at this low cost, high performance offering from Sparkfun.
#208039
OK, I have some interesting news. While scraping the web for info about debugging, I encountered a Yagarto page that said that Segger had an ARM development IDE. I went to Segger, and their site said that their Segger Studio development IDE is now free for non-commercial applications. Most importantly, Segger Studio claimed to support Ambiq Apollo3 processors. That was interesting enough that I had to spend 30 mins searching inside my closet of infinite contents in order to locate my old Segger JLink Edu hardware debugger dongle. I got it a long time ago before I started using the Atmel debuggers. With my JLink located, I downloaded the Segger Embedded Studio and started wading in. It appears to be mostly based on GCC, but I'm not sure if the linker is by GNU or if it is their own. The link command file syntax is similar to GNU, but different.

To make a long story short, I butchered together the Ambiq Suite libraries and the Segger Studio environment to make a hardware "Hello World" executable that would toggle the built-in LED on the Artemis Blackboard. It took afair while for me to get what appeared to be a suitable executable generated, but the real point of the exercise was to see if the IDE would really download and debug that executable. I pushed 'debug', and to my utter happiness, Segger Studio flashed the code onto my Blackboard and showed me the PC stopped at the opening brace of function main(). I could set breakpoints, run to them, stop and look around at variables and CPU registers. Single stepping worked in all its forms: instruction stepping, statement stepping, skipping over functions or stepping into them. Dang!

So there it is, a development environment that supports hardware debugging. Of course, it is Yet Another IDE, with all the baggage that comes along with someone else's view how an IDE should operate, and how a build process should be described, and what the build process should do. For me, hardware debugging is not a luxury but a requirement, so I guess I'll be learning Segger.

What's next: I really don't know the best way to connect Ambiq Suite to the Segger environment. My goal would be to work out the cleanest way to create an example "Hello World" that demonstrates integration of Ambiq Suite with Segger Studio, and use that as a starting point for future projects. But at least, now I know I'm working towards something that is useful for me!
You do not have the required permissions to view the files attached to this post.
#208045
That is very interesting and positive news. I plan to give Segger Embedded Studio a try. FWIW, the commercial use license for the Cortex M version is $1,248. However, at least two (and maybe more) microcontroller chip makers are providing a free commercial use license for SES when used with their chips. Ambiq -- are you reading this?

Robin - Please continue to post your experience with SES here.
#208107
> microcontroller chip makers are providing a free commercial use license for SES when used with their chips. Ambiq -- are you reading this?

I agree 100%! It's an easy way for a chip company to instantly provide a commercial-grade development product to support its silicon. I used to work at a company that made its own silicon and wrote its own custom tool chain to support that silicon (I wrote the assembler :) ). The silicon costs are obvious to a company, but the costs of homegrown tools are not. But when you have to pay someone else for the tools, those toolchain costs instantly become quantifiable and obvious, which immediately gets the attention of the financial management part of the company.

In other news, the Segger RTT interface you mentioned in an earlier post works "out of the box" with default SES builds. A hello-world program can include stdio.h and use printf(). As you mentioned, the printf() output goes out through the debugger connection to a terminal window in SES. That means that a project can utilize debug IO without needing to use any of the on-chip serial peripherals, so that all of the peripherals remain usable by your project. It's pretty cool!
#208134
Oh well. It was worth a try! Thanks for asking them.

I have finished the first cut at a document that describes how to use Segger Studio to build Sparkfun Artemis builds that are debuggable using Segger hardware debuggers. It also describes how to rebuild the HAL portion of Ambiq Suite so that the HAL operation itself can be viewed and debugged.

If you want to be a guinea pig and help debug the process in the document, send me a PM and I'll send you the doc. Fair warning: there are a lot of steps. If the process is unclear, incorrect, or most likely, if I missed documenting a step let me know and I'll fix it. When the document is debugged, I'll put it out for general consumption.
#208198
I went down a similar path with the Nordic NRF52, ended up using GCC, GDB and OpenOCD, see https://iosoft.blog/arm-gcc-lean-nordic-nrf52/
The difficult part is boiling down a complex buld environment into a simple makefile, but once that is done, development & programming becomes really easy & enjoyable, and I found GDB quite useable for debugging - and if you need a gui, there are some graphical front-ends around.
#208572
I am so happy to find this thread -- I have been struggling with the Apollo3 for the last couple of weeks and I share most of the sentiments you've expressed. Arduino setup is okay but limiting -- I've found the need to modify a lot of the libraries to the point where it's not scalable. So I tried to go the gcc + makefile approach --I have been trying hard to merge together a flexible Makefile from all the different repositories (Artemis Arduino Core, Sparkfun BSP, SparkFun Edge, Ambiq SDK, etc) but still no luck. For a good editor, I also looked into setting up with Visual Studio Code but that hasn't panned out well either. I can't believe the Apollo3 is so good on paper, yet there's not much support for it. Ambiq's developer forum has <20 posts, and none on (free) IDE setup.
#209150
Hi everyone! I don't know how/why I missed this thread entirely. I hope it's not too late to join the conversation and add a (maybe useful?) point of view. (Also I only managed to read through the first 3.5 or so posts thanks to the wealth of information provided in them - sorry if I repeat anything)

Working on the Apollo3 has been an exercise in developing our own tools/processes. The talk around SF is hinting at wanting to provide a more 'pro' solution to working with the Apollo3 and Artemis module. A good debugger solution will definitely need to be part of that package. If I may show you my preferred way to develop on Apollo3 right now:

Development
Editor: VSCode
SDK: AmbiqSuiteSDK 'Mirror' by SparkFun - includes tools that make life easier! And it's open-source so we can collaborate!

Debugger
I've tried many ways to do this and wasn't terribly happy with any. SES was the best option but I had to switch to another GUI for debugging :/ Just today I stumbled across this guide by SEGGER and am pleased to report that it is more or less working with my SEGGER J-LINK
https://wiki.segger.com/J-Link:Visual_Studio_Code

FWIW my launch.json file looks like this:
Code: Select all
{
    // Use IntelliSense to learn about possible attributes.
    // Hover to view descriptions of existing attributes.
    // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
    "version": "0.2.0",
    "configurations": [
        {
            "type": "cortex-debug",
            "request": "launch",
            "name": "Cortex Debug",
            "cwd": "${workspaceRoot}",
            "executable": "${workspaceRoot}/BUILD/EDGE2/GCC_ARM/mbed-os-example-blinky-baremetal.elf",
            "serverpath": "C:/Program Files (x86)/SEGGER/JLink_V642/JLinkGDBServerCL.exe", 
            "servertype": "jlink",
            "device": "AMA3B1KK-KBR",
            "interface": "swd",
            "serialNumber": "", //if you have more than one J-Link probe add the serial number here 
            // "jlinkscript":"${workspaceRoot}/BSP/SEGGER/K66FN2M0_emPower/Setup/Kinetis_K66_Target.js",
            "runToMain": true,
            "svdFile": "C:/Users/user/AmbiqMicro.Apollo_DFP.1.1.0/SVD/apollo3.svd",
        }
    ]
}

You can get the Device Family Pack for the Apollo3 (which contains the SVD file) here:
https://www.keil.com/dd2/pack/#third-pa ... oad-dialog


And I did not change my C/C++ configuration file (even though the guide recommended it)