Hi all- I just built my first board with a stand alone artemis, I developed firmware using the nano but now am trying to make something more manufacturable… as usual my board doesen’t work on the 1st attempt and I’m trying to figure out why… power seems good on the board for the artemis ant all peripherals… then i go to flash the artemis (with a segger swd flasher) and it tells me it’s a success. then the program(blinky) just doesen’t begin when I tell it to… I’ve flashed the nano many times before with the segger and it’s worked just fine, so I know i have the right offset and whatnot.
I have 2 possible candidates…
the 1st is the crystal, I tried to use the same circuit as on the nano(placing the crystal on bottom) and using 2 15pf caps… the one thing I couldn’t find was the crystal itself, it’s no longer listed on spark and I couldn’t find much info on it… I chose another 32768 crystal that expects a load of 12.5pf… is that ok?? I guess in the circuit the current flows into the tanks stacked in series, does that mean I should have a 7pf crystal?? If I think enough on anything I can convince myself of it. I guess I’m wondering what that spec means and if someone could point me towards the crystal found on the nano (or prefferably one that was tc).
my second theory is the BOOT pin used by the svl bootloader, I didn’t wan’t to put any of the usb/340 stuff on here so I was just trying to use the header for the debugger and skip all that, I do have a 10k pull up on the rst pin but I don’t have one on the boot pin… do I need this? is this a special hardware pin for the factory bootloader or a gpio used by the sparkfun boot loader that I overwrote?
I do have a 3rd theory which is that I just used way too much solder paste and smudged everything together… I lifted the artemis from my 1st board and made a real mess of it, but it’s hard to tell if that happened when I soldered it or when I unsoldered it… either way, I don’t like to blame the soldering…
anyways if anyone has any suggestions thanks in advance 
You can easily test for both of these issues on one of your stock boards - remove the theorised components and see if they still work. Let everyone know how you went.
I can tell you that the crystal is only for the RTC (I’ve had boards run without it soldered properly). The pulldown resistor on the boot pin looks important.
I’ve made a couple of detailed posts about my experiences manually soldering Artemis modules. Using a soldering iron to tin both board and Artemis module before you carefully place and then hot-air it, is the most reliable way to get a suspect solder paste job working in my experience.
The exterior crystal is in fact for the RTC. The crystal to provide the main clock is included underneath the RF shield. You do not need to have this component.
The BOOT pin is in fact a hardware strapping pin that is used to trigger the Ambiq Secure Bootloader (ASB) (which is a protected feature of the silicon). By not pulling the boot pin one way or another it is possible that you are always entering the bootloader, which has no timeout.
When you flash the Nano with your probe it is possible that you are relying on the SparFun Variable Loader (SVL) to jump to 0x10000. You said you overwrite the SVL so I assume that means you are flashing at 0xC000. That should work in either case while flashing to 0x10000 only works if the SVL is present.
It might not apply to you if you want to just flash your boards with a probe but it is possible to reconfigure some aspects of the ASB using “[create_info0.py”
This includes baud rate, boot pin polarity, and a lot more.](AmbiqSuiteSDK/tools/apollo3_scripts/create_info0.py at 05219eb4c827313c14a62122fbc5c9d80829042b · sparkfun/AmbiqSuiteSDK · GitHub)
thanks liquid + stephen, I’ve found my board super difficult to re-solder ;/ so I’ve been playing w lifting+replacing both the clock and boot pull downs on the nano and you’re right, the internal crystal runs in free run if no xtal is present… thats all well and good… as you said the boot pin does need to be pulled low or it enters the hardware bootloader… if you leave it floating(like i have) you can get lucky if it floats low at the right time.
I’ve been flashing to 0xc000 and just overwriting the svl bootloader, I made most of my firmware w the nano though, using the svl bootloader so it is handy ;)) now this business w the create_info.py, this is useful I guess, I think if I played w the secBootOnRst thing I could disable the bootloader entirely?? that’s an option I guess but I think I have to re-spin this board anyways so I’m just gonna take the hw pull down approach.
thx a bunch, cc