SparkFun Forums

[marsfan]

Just looked through the 1V6 guide, and I thought it was great, but I ran into a few issues (Though it probably does not help that I have never used SES before ) that were not really covered by the guide that I wanted to mention in case others have the same issues that I did.

[*}SparkFun now maintains their own fork of the Ambiq SDK. It has a single submodule with additional Board Support Files that they wrote for their products. https://github.com/sparkfun/AmbiqSuiteSDK. Make sure to double check all paths in the document when doing this

• When you first set up the project, the following is what you should see for the file structure
  • Setup
    • SEGGER_Flash.icf
  • Source
    • main.c
  • System
    • Cortex_M_Startup.s
    • SEGGER_THUMB_Startup.s
  • Use forward slashes (/) everywhere. I had a few things that got messed up when I used backslashes \
  • You should only have two configurations: "Debug" and "Release". If you see more than that, you selected the option to create a project using both Internal and External Tools. (This threw me off for a while).
  • Segger cannot assemble its own assembly file if you are using the SEGGER assembler. This is because Segger's assembler does not support multiline comments. The fix is to right click on the project->select options and set the compiler to gcc.
  • All config options that you changed other than renaming the
    Code: Select all

    DEBUG[\code] preprocessor definitions and setting the debug/optimization levels should be applied to the [i]common[\i] configuration. This is then set them for both the [i]debug[\i] and [i]release[\i] configurations. 
    
    [*] The [i]memory segments [/i]option is no longer in the [i]build[/i] section. Instead it is in the [i]Linker [/i]section
    
    [*] The [i]additional linker files[/i] is now called [i]Additional Input Files[/i]
    
    I can't guarantee that all of this works, as I do not have a J-Link (yet). But it seems to run fine in the Simulator built into Embedded Studio.

[robin_hodgson]

I'm glad it helped. I am up to version 1.8 of the doc. There were a couple mistakes and some improvements incorporated between 1.6 and 1.8. At the moment, I am waiting for Segger version 5 to settle down a bit. I think that Segger V5 simplifies a lot of the process described in that document. I think that a V1.9 doc would be a lot simpler.

The downside is that as part of the V5 Segger release, they "improved" their Segger runtime library, and as of V5, it is the only one you can use. The problem is that the improved runtime library got released a bit too early. In particular, it is not fully implemented so certain runtime routines I had been using don't exist anymore. Reading the Segger forums showed that I am not alone. Segger says that the entire library will be released at some point, but it is not clear when that would be. That seems like a serious misstep to me, but I don't work at Segger and don't know what is going on inside their engineering & marketing heads. I have worked around the missing routines in the one project I have migrated from V4 to V5, but it is an annoying enough issue that I am not migrating the rest of my projects until the library fully exists.

I don't know what to make of Sparkfun maintaining their own fork of the SDK. I have reported a bug in the 2.5.1 SDK to Ambiq over 3 months ago and never even received acknowledgement of the issue. I even sent them the fix. Their bug management system says that the issue is "open". So that was sad. Does it mean that we fix the bug in the Sparkfun fork? Is that not a recipe for needless divergence? I don't really want to go down that road.

Looking back, when I started with the Artemis, Segger was the only game in town for debugging an Apollo3 (at least that I could make work). There are other choices now, but I am used to the Segger development environment, and actually like it a lot. It's as good as anything out there. My opinion, obviously.

I still encounter problems debugging, but they are due to limitations of the Apollo3, not Segger. For example, on most other processors I have worked with, when you hit a breakpoint, you can arrange for the timers to stop counting whenever the processor is halted. That allows you to singlestep and poke around and then take off again without disturbing the time. The Apollo3 processor does not support that. If you hit a breakpoint, the timers keep counting. In general, I am not a fan of the Apollo3 timer functionality. But I suppose that statement deserves a thread of its own.

[marsfan]

Robin,

I know that Segger now has templates for the Apollo3, but it uses a linker files or something. Not sure how to change memory map to support the SVL.

Where can I find the newest versions of your tutorial doc? On a github repo?

The SparkFun fork is more of a mirror than a fork, but it has their Artemis BSP files integrated in as a Git Submodule. I don't think they changed any of the core SDK, but the presence of their own BSP files is enough for me (even though I don't know how to use it yet). They do have a bug tracker, but from their commits I don't think they are personally patching anything, at the very least, you could post there to draw Sparkfun's attention to the issue, and they might have better contacts with Ambiq than we do.

[robin_hodgson]

Not sure how to change memory map to support the SVL.

Maybe I am misunderstanding your statement, but all you need to do is link your code to start above the first 64K of FLASH and you are good to go. The Artemis bootloader lives in ROM, and the Sparkfun SVL bootloader uses 0x00000000 through 0x0000FFFF. The section in your 1.6 doc called 'Linker Process Mods' explains how to avoid overwriting the SVL using the linker. All you need to know is that if your code begins at 0x00010000, the SVL will make sure that it runs.

I will try to attach a copy of V1.8 to this topic. I have had bad luck with that though. I don't have a github repo for it - I am a luddite.

[robin_hodgson]

Hey, it uploaded!! Sweet!

[marsfan]

Cool. Going to see what changed with V1.8.

What I mean is that now if you download the Ambiq support package with Segger's Package Manager, when you create a new project they have special Ambiq templatess that don't use the same method of configuring memory, as the Memory Segments[\i] displays None[\i], and it uses a little bit different setup of the initial files, with the Apollo3 Vectors in a seperate file. Its probably useful, I will just need to play around a bit before I know for sure what it does.

See the attached images of the new Ambiq template options, extra config page during project creation and the file structure.

[marsfan]

Hmm. Not all images attached.

[robin_hodgson]

That probably makes sense because a generic Ambiq build would not know anything about a Sparkfun SVL bootloader. To support the SVL bootloader, just change your project/options/linker/memory segments as in the screenshot below for FLASH1. The RAM1 definition only matters for my project.

[marsfan]

Ok. So I tried using the Ambiq templates that Segger now has built in. They use a older version of the Ambiq CMSIS files than you can get through Sparkfun. The end result is that if you use it, you will need to do a lot of tweaking to the configuration files to get Sparkfun's examples working, as they use defines that are not in the older CMSIS versions (related to IC revision checking).

However, there are a couple of notable differences that the Segger template provides from what Robin's tutorial documents suggest. So far I have found:

• The CMSIS Files are in a folder that SES creates in the project.
• The Vector Interrupt Definitions are done in a seperate file. (apollo3_vectors.s)
• Additional IRQ vectors are defined at the end of the vector table. (The part with all of the .word stuff.
• The empty set of points that for the bluetooth subsystem are not configured.

.

Does anyone know what the reasoning is for the last two bullet points? I have uploaded the startup files below for reference. (I had to change the extension, as the forum does not allow uploading files with the .s extension.

[marsfan]

Robin,

I have been having some weird issues regarding the assembly file and the assembler saying "changed section attributes for .vectors".
I have noticed that my .vectors section is previously defined as "a" instead of "ax". Should I be changing that in the patchable.

Also, Is it possible for you to put a working SES template project up on Github or something? Might help people with getting started.

[robin_hodgson]

Segger is built on top of a bunch of different toolchains. I am using GCC as the compiler and assembler. Is that what you are using?

To just get going, you might try using Segger version 4.52C, which I think was the last version before version 5. Segger supports installing/running multiple releases at the same time so you don't need to uninstall your V5 Segger Studio. Using V4.52C (the final release before V5), then all the examples in my Segger doc will work properly. Once that is working, it is a relatively small matter to migrate from V4 to V5. Segger has a webpage describing the migration process. But as I mentioned earlier, you might want to use V4 for a while anyway because the V5 runtime library has some holes in it (as of the time of this writing).

I could put up a project template but they are all kind of particular to the way I use the Artemis: C++ projects using FreeRTOS with some fake Arduino libraries to simplify porting 3rd party code into my environment. That said, I thought it might be interesting/useful to make a tiny example SES project that shows how to use a GPS module to automatically calibrate the Apollo3 XTAL clock divider chain. Frequency counters are expensive, but GPS modules are basically free. It is on the "to do" list, which unfortunately just gets longer with time.

[marsfan]

Robin,

I might have to look into that. I am currently trying (and failing) to set up a super-minimal "Hello World" project that I can use as the basis for other projects. Right now I can't seem to get all of the Sparkfun BSP stuff setup correctly.

[marsfan]

Robin,

Where did you find all the information on the BLE Patch table that you talk about in the guide? I cannot find anything about that patch table other than the CMSIS file that you reference, but that does not have as much information as you discuss in the guide.

[robin_hodgson]

In the doc, I was speaking in generalities about how patch tables are typically used. I believe that the Apollo3 bluetooth implementation actually has some active patches these days, but I am making that statement from memory. I have never used the bluetooth yet, so I haven't worried about the details of the patch table.

[marsfan]

Ah ok. I managed to get a really simple blinky program working using the Ambiq template package that SES now has, how to download programs to an Artemis even without a J-Link (I found it useful, as I was still waiting for mine to arrive in the mail when I got started with this), and have kind of figured out how to use a lot of the other folders that are in the SDK (devices, BSP, etc), but because SES compiles all files in the project explorer it will have errors if some of the files that I am not using have an error in them, and if I just add them to the system path, it claims it cannot find the functions (possibly related to the functions declared as etern, but I am not too sure).

It seems that a patch table is not necessary so far (though I am not using the BLE stuff yet).

One other weird issue that I keep running into is that some programs seems to cause a jump to weird memory locations that the result in SES saying "Error reading from memory address 0xNNNNN". One example is the SparkFun BSP example hello_word_uart, which gets to memory locations between 0x200 and 0x500. I suspect it is being caused by interrupts, but I am not 100% sure. Have you run into this?

I have a big markdown doc I have been using to document everything I figured out that is based off of your guide with tweaks to cover using the template that SES has in v5.40. Once I figure out the debugger memory address issue I plan to put it up on GitHub and post it on this forum as well. Thanks for the help here so far, the guide really helped me start figuring out how SES works, and how SWD debugging works in general, as all of my previous experience with debugging is on boards with one built in, so setup was automatic.