SparkFun Forums

[robin_hodgson]

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.

[marsfan]

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.

[robin_hodgson]

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.

[marsfan]

The function am_util_delay_ms() calls am_hal_flash_delay() , so I suppose we are having the same issue.

[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.

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.

[Airheadbit]

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. 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.

[dcomer]

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?

Thanks in advanced for your time...
Dave

[robin_hodgson]

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.