A first look at the PCBs

A project log for Spy Thing

A tracking device with GPS, a digital microphone, LoRa transceiver, and an STM32 microcontroller.

Ville TiukuvaaraVille Tiukuvaara 12/05/2017 at 03:580 Comments

Soldering at Home

I ordered and received a batch of five PCBs and a stencil from EasyEDA a few weeks ago, and have since soldered them together and done a little bit a programming. With the large number of surface mount components, I decided to try my hand at the reflow skillet method with a 40% success rate so far. Well it's really 0% because all of the them had shorted pins and needed rework, but that is to be expected.

Reflow skillet soldering
Using an IR thermometer to heat the PCB to 250 celsius.
Reflowed PCB
There was plenty of rework required after reflowing. Many shorted pins and some misaligned components are visible.
First reflow attempt
My first attempt at hot plate reflow soldering was disastrous and resulted in a bad smell at home for the rest of the day. Now I do this in the garage.

I used SAC305 (lead-free) solder paste, which melted at around 200 celsius. I quickly found out that it's important not to go much above 250 celsius since I melted one of the PCBs. Afterwards I fixed up the shorted pins with a microscope, soldering iron, and some solder wick. I was able to program three of them, although one of these stopped working.

Lessons learned so far:

  1. Make sure there are test points for all important signals. I only had one VDD connection (through the programming header) and wish a had a dedicated 2-pin header for power.
  2. The NRST pin on the STM32 micro controller needs a decoupling cap. It is internally pulled high, but this is needed to prevent unwanted restarts. So far I have been hooking up a Nucleo programmer to debug, and I'm guessing it also pulls NRST high.
  3. Avoid through-hole components. Because of the through-hole pin header, I was unable to do any reflow soldering after connecting it.

SD Card Woes

With two programmable boards, I tried to get the SD card working (firmware repo is here). SD cards support three forms of communication: 1-bit SD, 4-bit SD (for increased throughput), and SPI (easier and more commonly used by hobbyists). The STM32L476 has an SDMMC peripheral that allows the 1 and 4-bit modes to be used. I used the CubeMX software from ST to generate the backbone code for the project and then used the CubeMX importer (a python script) from Carmine Noviello to import it into a project for working with the ARM GNU plugin in Eclipse. This is all described his book, which I recommend.

CubeMX makes it easy to set up a project. It even configures FATFS (although I am getting skeptical that it's doing it correctly).

CubeMX also allows FATFS to be configured to use the SD card, so it was quite easy to get the project set up. FATFS is a library for working with FAT16/exFAT filesystems. My plan is to use it to store audio recordings from the onboard mic onto the SD card. Unfortunately, it is not so easy to get FATFS working. I have so far gotten 1-bit mode to work on an SDHC card (SDHC is the second SD card standard for cards up to 32 GB) but not on an SDSC card (older standard for <4GB). SD cards have a microcontroller and a state machine, and require a careful initialization sequence including checking the supported voltage. This initialization happens in 1-bit mode at <400 kHz, after which a command (ACMD6) can be sent to switch to 4-bit mode for more throughput and the clock frequency can be increased. So far the performance has been very inconsistent. I was able to switch to 4-bit mode perhaps once. I am not sure if this is because of the SD clock frequency I am running at, which I have experimented with seemingly no improvement. I have tried frequencies from 100 kHz to >20 MHz.

In 1-bit mode, where I am able to initialize the SD card, I am then unable to write a file, using a FAT16 file system. While FATFS is able to create a new file, it is unable to write to it. Checking the SD card afterwards, there is a new empty file. Since it has created the file (with a name) it seems that FATFS is able to write to file allocation system but then unable to correctly write to the cluster containing the file. It could also be SD communication errors. I am not really sure where to look, and unfortunately I don't have the SD signals broken out. :(

Digital MEMS Mic

On the bright side, I have gotten the digital microphone to work. ST has a demo for its MEMS microphone Nucleo expansion board, which I ported for my custom hardware. This uses the DFSDM peripheral to interface to the mic, which outputs pulse-density modulated (PDM) audio. Sampled audio is usually represented using pulse-coded modulation (PCM), which means each sample is represented by a number of bits (16 bits for audio CDs). PDM is essentially PCM with only one bit. In order to have the same audio "information", PDM is oversampled (you can read about it here). Fortunately, the DFSDM peripheral on the STM32L476 is able to decimate the PDM audio and produce a PCM stream. It does this in the background as well, not requiring extra processing power! The demo from ST also uses USB to present itself as a USB microphone.

I had to minimally modify the demo so that it used to the correct DFSDM channel 0 for the mic, and increased the sample rate to 32 kHz. The code is here. The board showed up as a USB device and I was able to record some audio using Audacity. It sounds pretty good too!

Microphone test
A demo where the board shows up as a USB mic.
USB Audio Device
The board shows up as a USB audio input device.