I had thought to silkscreen an outline of the Artemis on the board to help me place it. My outline was designed be just visible on 3 sides when the Artemis was set down in the right spot. I don't have a vacuum pen, so I used tweezers to hold the Artemis by its bluetooth antenna. Maybe I got a bit lucky, but it set down fairly accurately, and I only had to push it a little bit to get it centered up. That had me worried the most that I might be smearing the solder underneath.
But that's what I was going with, so I headed out to the garage. After 6 mins in the toaster oven, it was back to the bench. The board's power lines Ohmed out OK with no opens or shorts. But just in case, I set the power supply on a current limit of 10 mA and then powered the board. No smoke!! A good start. The current meter said that the board was drawing less than 10 mA, so nothing bad appeared to be going on. Another good sign.
Then it was time for firmware. I soldered down the SWD debugger header and attached my JLink. To my total happiness (and amazement, honestly), Segger Studio recognized the processor, flashed my firmware, and stopped at the first line of main(), ready to go. Single stepping worked, the on-board LED worked, and the GPIO pushbutton worked. Woo Hoo!
Then it was time for the first big test. I added the connector to plug in my AC current sensor daughterboard. The daughterboard uses an I2C IOM interface. And.... it fired right up and started printing current measurements to the Segger debug output window. That meant that the Apollo3 VCOMP voltage comparator connections were working too, because that's how my current sensor knows when to wake up and start sampling.
Next up was the SPI IOM that talks to the RFM95 LoRa radio. I had to make a cut and jumper before starting. In a fit of stupidity during the design phase, I had connected the radio's RESET signal to the general system RESET signal. That works, but the radio RESET really needs to be controlled by a GPIO so that the radio driver software can reset the radio as required. I cut the RESET trace in a convenient spot and added a jumper from the radio socket pin over to one of my collection of spare GPIOs that were routed to a 12-pin connector on the board for just such a purpose. I always put some spare GPIO connections on the first few versions of a board until I either need the space, or everything is working perfectly. Anyway, I fired up the board again and used Segger to single-step through the process of resetting the radio, and performing the initial SPI communications checks. The SPI interface worked fine in both directions. Score!!
The only things I haven't tested yet are:
- Battery operation, including reverse battery protection circuitry
- USB/serial daughterboard for communications and as an indirect source of AC power (via USB)
- QWICC interface
The only bummer in this whole process so far is that my module firmware reports that the processor is the A1 silicon revision with its deep sleep power consumption bug. The board is meant to be powered by a CR123 battery and I want it to live outside for years between battery changes, so having the A1 throw power on the ground is not great.