Code name "Swiftlet" - PCB populating and bringup

Projects / Project Swiftlet  Original post date: 08/28/2015

Quick executive summary:

☑ ChibiOS compiles and runs.
☑ 3.0V/1.5V buck converter works.
☑ 3.0V LDO works.
☑ 3.3V boost converter works.
☑ Li-ion charger works.
☑ Debug cable - SWD connection
☑ MCG working with 32.768kHz crystal and FLL.
☑ My replacement for _pal_lld_init() (for configurating/initializing GPIO) works.
☑ Serial port setting and my debug shell works.
☑ Input battery voltage sensing and power selection works.
☑ Sonar receiver works with the barnacles that fixes the two following issues.

X U12A, mU12B, U12D: All of the inverting and non-inverting inputs are reversed!
X Receiver virtual ground impedance is too high causing oscillation.

☑ Haptic motor driver works
☑ Class D amplifier works
☑ DAC works after the barnacles

X DAC BICK & LRCK connection swapped.

After the long wait, the PCB finally arrived. Like my other PCB, the back silkscreen is missing. :( The silkscreen on this PCB is back to normal. As seen from below, the silkscreen is a bit offset. Thankfully I remove the silkscreen from most of the footprints.

Score PCB with a box cutter on both sides.

Snap the PCB

Repeat

Testing the Li-ion charger

☑ Li-ion charger working.

Trace between R1 & R2 not routed. R2 = 10K needs to be installed.

Had a bit of trouble of not having enough solder during reflow, but once I tin the chip side, then it is okay.

This was a much finer pitched QFN than I had soldered at this point.

Populating and testing power supplies for Li-ion and AA

☑ 3.0V/1.5V buck converter working.

☑ 3.0V LDO working.

☑ 3.3V boost converter working.

Solder the rest of the SMT parts. I leave out the through holes parts as I have no idea if they would survive a reflow in the toaster oven. The battery holders do not handle heat too well.

Pop it in the toaster oven just to make sure that the surface tension get to line up the parts.

Assemble the Sensor PCB and solder the two boards together.

The holes for transducer footprints are a bit tight as these are parts I pulled from pre-made modules, so there is a layer of solder on the pins that I didn't account for. The battery holders could still use a bit of space. I think the holes in the plastic posts are intended for self tapping screws.

The two 8-pins connector (Debug and expansion I/O) are a bit too close together. The IDC version exits at 90 degrees. So looks like I'll either have to kludge together something. Not a big deal as they are only for debugging and for me to get at the spare I/O pins.

The DF11 IDC connectors is a double decker - the bottom row is connected to the left column of the connector while the upper row is to the right. There is a plastic partition on the bottom layer to stop your wires getting to the right column. The connector takes 26AWG and it works for either loose wires or ribbon cables.

I used the back side of the box cutter blade to press down the wire until the insulation is pieced by the V shaped contacts. It makes an airtight connection and does not require any fancy crimping tools. This is the first time that I use this so I check all the connections with the continuity test on my multimeter and they are good. I would say this is a good system. The other end of that cable is split into to TTL serial adaptor and a SWD debugger.

SWD debugger detects something. It's ALIVE!

☑ Debug cable - SWD connection
☑ Microcontroller (not running any code at the moment)

I have added the headers for MDK's Configuration Wizard for some of ChibiOS options in hal_lld.h It is a lot easier than trying to figure out the hex values and a wrong one will permanently lock the device.

I got stuck on the NMI pin as it was enabled by default in ChibiOS and of course You would think that NMI_DIS = '1' would disable the NMI, but actually '0' does that! So having a GUI that spells things out will make life easier for the next person.

☑ Clock oscillator, MCG working. Wasted a bit of my time trying to change the clock setting when the code isn't called.
☑ My replacement for _pal_lld_init() is working better than the one that comes with ChibiOS.

You'll need access to the Reset pin as a way to access SWD if you run into trouble setting up the port pins, clock generator or stop/sleep mode. I made a small test pad for that. BTW, you can't even begin to do serial port debugging until you got the clock tree, I/O port, interrupts all configured correctly which can be tricky on the ARM, so using SWD is pretty much essential.

Found some hard coded constants inside serial_lld.c. No wonder why I couldn't change the baud rates and the oversampling rate. Got that fixed up with #define and now I see my familiar shell program. My shell program will make life a whole lot easier to try out small bits of code.

Seems like the power consumption at this point is around 13mA when powering the microcontroller from LDO. The current changes very little even when I am playing with different clock speed setting. Right now I am running the FLL at 20.971520MHz with the Core at 4.1943MHz (/5) and the bus/FLASH at 2.09715MHz (/2) as I am trying to converse power. At some point when I am playing with MEMS sensors that need some math, I might have to briefly increase the clock speed. Even with that type of clock speed, this will still have an advantage over a 8-bit trying to do math.

☑ Serial port setting and debug shell are now working.

I found the source for that extra 10mA of power drain. It turns out to be the power rail for the MEMS. With that tuned off, the power has dropped down to 2.9mA with the ARM running. It seems to make very little difference to what clock divider rate the ARM is running as (so far).

That extra 10mA seems to be kind of high when the datasheet talks about max 3mA during boot and ~600uA typ for full sampling rate. On the other hand, the part has not been initiated, so it is hard to say.

The efficiency of the 1.5V boost supply seems to get a bit better now that I got some of the power management I/O initialized. It went down from 24mA to 16.8mA and that's with more peripherals on the ARM going too.

☑ Input voltage sensing.

Changing the ADC filters C12, C13 from 0.1uF to 1nF because the RC time constant is a bit large.

Changing R10 to 220K, R7 to 1M, R9 to 562K because there is quite a bit of leakage current to the ARM ADC pins. Now the values are close to what they should be.

☒ U12A, mU12B, U12D: I forgot to flip the symbol vertically. All of the inverting and non-inverting inputs are reversed! This requires some surgery with barnacles.

☒ Receiver virtual ground impedance is too high causing oscillation

I guess I should actually trust the oscillation in the simulation and my gut instinct instead of the waveform measurements of the modules!? The new opamp that I am using has stronger drive which in turns feeding back to the virtual ground. The virtual ground impedance formed by 10K voltage divider and decoupled by a 10nF isn't low enough. A part of that output signal is injected on the reference virtual ground and causes oscillation.

I could use the uncommitted opamp as a buffer and according to LTSpice would work. I have decided to move the 1K virtual ground connection to GND. The latter makes no difference AC performance-wise to the bandpass filter and is much easier to fix. After fixing the miswiring and the resistor, the sonar receiver is now working. See here.

☑ Haptic motor driver working

The motor is driven from PWM with period, duty cycle, number of pulses and side (left/right/both) programmable. The following scope picture shows the voltage across the motor. I use dynamic braking so that the motor start and stop abruptly instead of coasting producing tabs. The motor is kind of small and I am not sure if I can sense its movement more easily than its noise.

There are still a lots of work to do.