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.
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.
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.
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.
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.
Strictly speaking, a patch table is not required even if you use BLE. It just means that you will be using the original mask ROM without any bug patches that may have been released. I don’t know how the BLE patches are released as I haven’t tried to use it yet.
Starting with the changeover from V4 to V5, I started getting “Error Reading from memory address 0x00000100” every single time a program gets flashed. That is an address in the Sparkfun SVL bootloader [0x00000000…0x0000FFFF]. I don’t know what is happening. I just ignore it and everything works fine after that.
I do know that you can replicate that style of error message by asking the debugger to access a peripheral that is not powered up. For example, load a program to flash and don’t run it, but just leave it sitting at the first instruction in you main(). Then go to the ‘Registers’ window, click on ‘groups’, and select ‘uart0’. You will see a ton of messages that the same error message about reading memory where all the memory addresses correspond to UART registers. That’s because the UART is powered off at that point in main(). If your program turns the uart on at some point, the messages go away and the registers in the UART window populate with real values.
So who knows. It seems like a transient issue that got introduced with the change from V4 to V5, and it appears that you can safely ignore it.
I reread your document and figured it out. I forgot to add in the VTOR initialization. That also got my interrupts fully working.
Have you tried unchecking the setting Restrict Memory Access? I stumbled across it while trying to fix my problem. It might fix the issues you were having.
I still get the error with some other stuff, such as the am_util_delay_ms() function. Looking at the code, that seems to be calling something in the bootrom. I suspect that some security feature on the chip, or the Ambiq Secure Bootloader, is blocking the debugger from reading it.
Have you tried unchecking the setting Restrict Memory Access?
I have now, and it makes no difference.
I have used the am_hal_flash_delay() routine since I started with Segger and it never caused an issue before. That delay is performed by bootloader ROM code. Something changed between SESV4 and V5 to cause this issue. The specific error I am seeing seems to be completely harmless though.
Long Term Update: Segger Embedded Studio (SES) is still working fine after many releases. I am currently using SES release 6.20 with my ancient J-Link EDU and it does everything I need.
The biggest change from when this thread started until now was between release 4 and 5 when Segger changed their runtime library. Using the new Segger runtime library was optional in release 5, but as of release 6, it is mandatory. I switched over to use the new library at release 5, so this morning’s update from release 5 to release 6 was a total non-event.
Other than the library update, the changes between any of the releases have been completely seamless: download new Segger version, rebuild the projects, you should be good to go.
I still really like SES. I’m sure that these days there are lots of other options, but I’m invested in this solution and my goal is to make things, not learn new IDEs.
Here is the latest SES/Artemis project: a trailing-phase LED lighting dimmer.
robin_hodgson:
Long Term Update: Segger Embedded Studio (SES) is still working fine after many releases. I am currently using SES release 6.20 with my ancient J-Link EDU and it does everything I need.
-snip
I read your post from the start, all of them, tried mbed and wasted a day or two, finally downloaded SES 6.2, I had SES installed from Nordic but it is a 'Nordic' version. While looking for a means to use the ambiqmicro SDK without spending the time to follow your earlier guide I came across [https://github.com/schreinerman/AmbiqSu ... gerIDE.git](https://github.com/schreinerman/AmbiqSuite_SeggerIDE.git). Following the readme in the git it produced segger projects for everything in the AmbiqSuite SDK, Segger 6.2 compiled and debugged faster then I could look up to the screen.
After burning up a week or so by reading everything on the internet I looked into purchasing a compiler, IAR, Keil, Rowley, and Segger, Rowley won. Not that I don’t enjoy the challenge of making Open Source products work or hacking a SDK here and there but I’m running out of time and I need to get one interface that works with the four IDE products I’m using, every time I switch I have to relearn. I really did like Freescale’s Processor Expert, to bad they were purchased by NXP.
I wish Sparkfun would make the Artemis Arduino board support work like STM32uino board support does with the ability to debug and use HAL. You put a lot of work into your guide, thank you for the effort.
It appear that Ambiq Suite is no longer available. At least, I can not find it on the ambit.com site (nor does the link in you documentation work). Is there an alternate (e.g. has ember been absorbed by another company or made obsolete by Embedded Studio?
If you are referring to the AmbiqSuite SDK, I just checked and it is still available. They rearranged their website a while back and that might explain the broken links. Go to Ambiq.com, products, then select Apollo3 blue, then go to document download, and you will find the various versions of the SDK listed as being documents. If you download the appropriate SDK ‘document’ it comes as a big zip file containing what you need.
