SparkFun Forums 

Where electronics enthusiasts find answers.

Everything with the AmbiqSuite SDK tools and software are welcome here.
User avatar
By davidmdj
When running the AmbiqSuite/SFE SDK blinky example, I've noticed that the user (blue) LED stops blinking ~23.8 minutes (~1430 seconds) after a reset. Initially, I found this by accident after walking away from my desk... when I came back the user LED was solid blue. Then, I started timing the start to freeze time. I've confirmed this on an Artemis Redboard and an Artemis Redboard ATP.

I was hoping someone else could confirm this independently. It is not a huge issue, but it would be nice to know whether this is something intentional or a bug. I tried to look through the code, but I don't see any obvious reason for this behavior. I don't have a debugger, yet. This one is not that easy to debug using printf's.
User avatar
By davidmdj
The root cause of this is the STIMER capture/overflow interrupt, IRQ22, is enabled. When the STIMER overflows, the am_default_isr() handler is called. The STIMER will overflow after 2^32/3MHz = ~1431 seconds Then, the handler spins in an infinite while loop and the application appears to freeze. As a side note, am_default_isr() is the default handler assigned in startup_gcc.c to all the peripherals and 4 other handlers. It appears that the SF Artemis SVL bootloader is enabling this interrupt. So, the blinky example is not the only code affected by this. Any application that doesn't clear the STIMER capture/overflow interrupt while using the default handler will see this. So, it is always a good idea to pay attention to how the Apollo3 is configured before main() or immediately upon entry into main().
User avatar
By davidmdj
I should also note that the 3MHz used in the calculation above comes from the STCFG register CLKSEL field. Out of the bootloader, It is set to 0x1 corresponding to setting the STIMER clock source to HFRC_DIV16.
User avatar
By davidmdj
I'm a little surprised that no one from SFE has made any comment on this issue. This is subjective, but I don't think this should be the default behavior as many users will use the SVL bootloader. Or, at least document that behavior. It would save others debugging time. Before your reply, I thought I was the only one seeing this issue.
User avatar
By liquid.soulder
Hi all - until yesterday I had not been subscribed to this forum topic (only to the hardware topics for some reason, so I have missed A LOT of good conversations). Yes this is an issue! I'll take a look ASAP.
User avatar
By liquid.soulder
Arduino core is updated to v1.0.22 which updates the SVL to version 4. To see the benefits use the 'burn bootloader' option with 'Ambiq Secure bootloader' selected as the programmer from the tools menu.
User avatar
By fhanchek
I bought an Artemis ATP board this month, but it must be old stock, as it still has this bug and all programs freeze after 1431 seconds. Is there a trick to burning a new version of the SVP? Using liquid.soulder's instructions - use the 'burn bootloader' option with 'Ambiq Secure bootloader' selected as the programmer - just gives me error messages. I'm using the stand-alone IDE.

Arduino: 1.8.13 (Windows 10), Board: "RedBoard Artemis ATP, 115200, Ambiq Secure Bootloader (Advanced)"


at cc.arduino.packages.uploaders.SerialUploader.burnBootloader(



Error while burning bootloader.

 Topic permissions

You can post new topics in this forum
You can reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum