Do Artemis Module Designs Require Implementing the 32KHz Crystal?

I am writing a program that is doing a bunch of things with the Apollo3 clock mechanisms. I was doing some low-level debugging that involved setting a breakpoint at the very first instruction of my code image. To my surprise, I noticed that the 32 KHz XTAL was already enabled even though its post-RESET state is to be disabled. The surprise was momentary until it occurred to me that any program I write will inherit a bunch of initialization left over from running the Sparkfun SVL bootloader. But that made me surprised again: does the Sparkfun SVL bootloader on an Artemis module require an XTAL to operate? If not, why did it get enabled?

Since the Apollo3 processor does not actually need an XTAL to operate, I had assumed that the presence of the 32 KHz XTAL in an Artemis design would be optional. But perhaps the Sparkfun bootloader turns on the XTAL so it can operate reliably at much higher transfer rates than the Ambiq bootloader. That would be fine, except for the implicit dependency that every Artemis module design will require a 32 KHz crystal.

So: does anyone know if the SVL and/or Ambiq bootloaders require the 32 KHz XTAL?

Hi Robin, I’ve done various messing about with crystals (resulting in them being absent or non-functional) and I’m fairly sure everything has worked normally without a crystal, including a reset and bootload. Easy enough to de-solder one if you are curious enough and want a definitive answer.

I found the source code for the SVL bootloader at Github and it does not use the crystal. I would be really surprised if the Ambiq bootloader did either. Now I am wondering if a debugger RESET does not completely reset the chip. Or maybe I just missed something obvious in my initial observations. I’ll report back when I get to the bottom of it.

robin_hodgson, did you ever get this to work? I am able to program the module, but can’t it to connect over BLE. I’m also wondering if this is an external crystal issue. Thanks.