I’m using the SparkFun MicroMod Artemis Processor Board on a custom carrier and I’m checking the Apollo3 Blue errata regarding power-up ramp behavior.
According to Apollo3 Blue Errata ERR029 (“Flash: Bit flip due to VDDH/VDDF power-up race condition”), a hardware workaround may be required for certain VDDH ramp-up times, specifically a bootstrap capacitor between VDDF and VDDP/VDDH (not just decoupling to GND).
Question:
Was this ERR029 hardware workaround capacitor (VDDF ↔ VDDP/VDDH) implemented on the SparkFun Artemis module / MicroMod Artemis Processor Board (and if yes, in which hardware revision)?
I’m asking specifically about the capacitor between those two internal rails, not the normal VDDF-to-GND decoupling capacitor. (Ambiq’s hardware design guidance also references the VDDF-to-VDDP capacitor for Apollo3 in connection with ERR029.)
No…searching the forum history leads me to think it may be a fairly uncommon issue that may be worked around with delays? The searchable history covers the Apollo3’s lifetime for us, so it doesn’t appear to come up much
Over the years I have done many projects with different boards based on the Apollo3 processor from Sparkfun, including the MicroMod, and I can only echo TS-Russell: NOT ONCE I have experienced that problem.
Thanks for the clarification and for checking this internally. Even a little more detail on ERR029 would be very helpful.
I agree that the absence of known cases is somewhat reassuring. However, I am not sure that this alone proves the issue is negligible. A flash bit-flip during power-up might not produce a clear signature and could instead appear as rare, strange, or unrelated program behavior, making it very difficult to trace back to ERR029.
Also, since the Apollo3 Blue has a fairly large flash, and many applications may use only a limited part of it, the lack of reported cases could simply reflect a lower statistical chance of hitting an affected location.
Would SparkFun perhaps be able to use its position with Ambiq to get a bit more detail on this erratum? Even limited information on how often it was observed, how sensitive it is to ramp shape, and how narrow the problematic region is would help a lot in judging its practical relevance.
In my current design, I achieve about 165 µs rise time on the 3.3 V MCU supply rail, measured directly on the Artemis MicroMod Processor Board. That sounds promising, but it is still very close to the <180 µs limit in the erratum. So I am not sure whether this can already be considered safely outside the risk window, especially since the erratum refers specifically to VDDH ramp-up.
So from my perspective, “no known field reports” is encouraging, but not fully conclusive.
I can ask but we really only interact with the Sales team, who’ll likely tell us whatever we wanna hear :-p
It might be worth posting on the Ambiq forums…but I googled for a while and didn’t find much, between the lack of results on the github GitHub · Where software is built (searched ‘ramp’, ‘vddf’, vddp’) and the lack of threads on our forums it doesn’t seem emergent as a pitfall
Are you doing something where data is mission-critical (like, for the DoD)?
