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.
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().
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.
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.
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.
They still need to be tested and then migrated into Arduino - and then to see the changes users will have to re-flash the bootloader using the provided tools. We will also release documentation advising people to do so.
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.
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.
