Awesome stuff!
Robin- First I want to thank you for the excellent job in creating the guide for using Segger Embedded Studio with Artemis.
I have followed the instructions in your guide and I was able to create, compile, flash, and debug the Hello World sample on the Artemis red board
Next, I have tried to import one of the example projects from the Ambiq SDK V 2.2.0 under AmbiqSuite-Rel2.2.0\boards\apollo3_evb\examples\ble_freertos_amdtps\keil that I could build with Keil with no problem. However, I was not able to build this project with SES as one of the files could not compile due to the following error as you can see in the attached snapshot:
#35: #error directive: This port can only be used when the project options are configured to enable hardware floating point support.
When compiling the project with Keil, there is no such problem but it happens when building with SES.
I am new to SES and I do not know how and where to set the __TARGET_FPU_VFP directive for the compiler when using SES.
I would appreciate any help.
Congratulations, you have found one of the main updates between version 1V6 and 1V7 of the doc. My apologies for not publishing version 1V7 before now. I had been worried about generating endless versions of it so I had been sitting on 1V7 until more reports came in. Yours is the first one in 6 months, and 1V7 already covers it, so here we go…
I will attach the 1V7 version to this thread for completeness. In the meantime, here is the specific section within it that may fix your problem:
The Apollo3 is a Cortex M4F, meaning that it supports hardware single-precision floating point. Segger needs to know that when it builds, it should use the “hard float ABI” to take full advantage of the hardware floating point mechanisms that are present in the Apollo3. To do that, click ‘Project/Options/Code/Code Generation’, then click on the ‘ARM FP ABI Type’. Use the pull-down menu to select ‘hard’. The ‘soft’ options are for processors that do not support hardware floating point, or perhaps if you needed to interface to a binary library that was built with soft FP. Since the point of this whole section is to build Ambiq Suite as part of a project, it works best if absolutely everything is using hard FP.
Select the option in your project as above, and rebuild everything clean. It should work at that point.
Well, I would like to attach the 1V7 PDF document, but this system is barfing:
I have tried resubmitting.The submitted form was invalid. Try submitting again.
Thank you so much Robin for your quick response. I changed the FPU option to FPv4-SP as you suggested and I was able to successful compile all files in the project 
.
However, during the final link phase, it came up with the following error:
L6031U: Could not open scatter description file .ble_freertos_amdtps.sct: No such file or directory
I am anxiously waiting for V1.7 of your document. I also had the same upload problem on this site when attempted to attach the snapshot of the error.
The “.sct” file is a Keil-specific linker file which is not going to work with Segger. It appears to explain to the Keil linker where the SRAM and FLASH sits in the Apollo3 address space.
To be honest, I am not sure how to build those examples. Try building from the GCC directory as a starting point instead of the Keil directory just to make sure that your build is not accidentally including any Keil-specific things. Also, make sure that you have done all the Segger linker setup as described in the 1V6 doc. If you do all that, there will be no reason for the build system to look for a".sct" file.
I can successfully build from the gcc directory using the command line in git bash and GNU Tools for ARM and provided makefile under that directory. However, unlike keil, gcc is not one of the import project options supported by SES.
I guess I need to read your guide more carefully and make sure I have not left anything out. Thanks again for your help.
Going back to your original post, the error was “L6031U: Could not open scatter description file .ble_freertos_amdtps.sct: No such file or directory”. I can see that file located in the Keil project directory, so if SES is generating the error message, then maybe it needs to have a path described somehow because the file certainly exists. Sorry, I’m not going to be much more help: I didn’t even know that SES could import a project! 
As you mentioned, the missing file (without the . at the front) is under the Keil project directory. So, after I copied that file to another file with the same name but with . prefix, it did passed the previous link error but now it reports:
Linking ‘ble_freertos_amdtps.elf’
L6366E: am_hal_global.o attributes are not compatible with the provided attributes .
L6367E: am_hal_global.o(.rev16_text) attributes are not compatible with the provided attributes .
L6367E: am_hal_global.o(.revsh_text) attributes are not compatible with the provided attributes .
L6367E: am_hal_global.o(.rrx_text) attributes are not compatible with the provided attributes .
L6367E: am_hal_global.o(.constdata) attributes are not compatible with the provided attributes .
L6367E: am_hal_global.o(.constdata) attributes are not compatible with the provided attributes .
L6367E: am_hal_global.o(.data) attributes are not compatible with the provided attributes .
L6366E: port.o attributes are not compatible with the provided attributes .
L6367E: port.o(.rev16_text) attributes are not compatible with the provided attributes .
L6367E: port.o(.revsh_text) attributes are not compatible with the provided attributes .
L6367E: port.o(.rrx_text) attributes are not compatible with the provided attributes .
L6367E: port.o(.emb_text) attributes are not compatible with the provided attributes .
L6367E: port.o(i.SysTick_Handler) attributes are not compatible with the provided attributes .
L6367E: port.o(i.am_stimer_cmpr0_isr) attributes are not compatible with the provided attributes .
L6367E: port.o(i.prvTaskExitError) attributes are not compatible with the provided attributes .
L6367E: port.o(i.pxPortInitialiseStack) attributes are not compatible with the provided attributes .
L6367E: port.o(i.vPortEndScheduler) attributes are not compatible with the provided attributes .
L6367E: port.o(i.vPortEnterCritical) attributes are not compatible with the provided attributes .
L6367E: port.o(i.vPortExitCritical) attributes are not compatible with the provided attributes .
L6367E: port.o(i.vPortSetupTimerInterrupt) attributes are not compatible with the provided attributes .
L6367E: port.o(i.vPortSuppressTicksAndSleep) attributes are not compatible with the provided attributes .
L6367E: port.o(i.vPortValidateInterruptPriority) attributes are not compatible with the provided attributes .
L6367E: port.o(i.xPortStartScheduler) attributes are not compatible with the provided attributes .
L6367E: port.o(i.xPortStimerTickHandler) attributes are not compatible with the provided attributes .
L6367E: port.o(.data) attributes are not compatible with the provided attributes .
information, 0 warning and 25 error messages.
Build failed
Do you know if there is any attribute compatibility options in SES that can be set/changed to overcome this problem?
Did your build create “am_hal_global.o” and “port.o”, or is it linking to some pre-built .o files that may already exist in some example directory?
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 :D) 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
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.</LI></LIST></LI></LIST>
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.
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.
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.
Artemis for Segger Studio 1V8.pdf (390 KB)
Hey, it uploaded!! Sweet!
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.
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.
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:
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.
apollo3_Vectors.txt (8.31 KB)
Apollo_Startup.txt (8.47 KB)
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.