Close

32-Bit & Wireless: The Pro Mini nRF52​

A project log for Searching for a better Pro Mini

I LOVE the Pro Mini! But it has limitations. To overcome some of them, I’m designing the Pro Mini XL & Pro Mini nRF52. What do you think?

andyAndy 04/25/2019 at 14:070 Comments

Above: Pro Mini nRF52 (right) shown next to a Pro Mini 328p clone (left).

(Note: An early development Pro Mini nRF52 shown with edge SMA, through-hole and U.Fl antenna pads.)

In the beginning

Shortly after the Pro Mini XL was born, I could feel the 32-bit world calling with its technological siren song.

Microcontrollers in this space boasted faster speeds, even more program memory, DMA, etc.

All very enticing for solving my Pro Mini problems.

One of the realizations I came to after creating the Pro Mini XL, was that I was obviously still board-stacking.

Many of my more recent projects had gone wireless, especially in the area of Home Automation.

I found myself adding nRF24s, RFM69s, 95s or RN2903s to get the range and/or protocols I needed.

And then there was encryption, “uniquification”, and over-the-air updates.

I had boards with ATSHAs, EUIs and additional SPI Flash amongst other things.

Add power distribution, monitoring, battery charging and actuators and we’re already at a 5+ board stack!

So I took the 32-bit world’s red pill (or rather “Blue Pill”) and began to explore.

I decided to focus my initial efforts on 32-bit microcontrollers that had built-in radios that I was already using.

This lead to the natural selection of Nordic’s nRF52832.

Benefits

The nRF52832 is a 64MHz ARM Cortex M4 CPU (with FPU), 512KB flash (!) and a built-in 2.4GHz transceiver.

The transceiver also supported Bluetooth 5, Bluetooth Mesh and ANT - which all sounded interesting.

Scratch one radio board from my stack.

Just as interesting was 128-bit AES/ECB/CCM/AAR (for encryption), 64KB RAM and 32 configurable GPIOs.

Scratch at least one more board from my stack.

All of this board-scratching sent me ferritting about for how to best get my hands probes on one.

What confronted me was a veritable sea of modules and dev. kits, many of which were breadboard hostile.

Most of the modules I saw had castellated pads requiring mounting to another PCB before use in my stack.

A Pro Mini-sized board only leaves approx. 13mm between the right and left hand side edge pins.

Modules that had metal shielding (for FCC certification, etc.) were simply too wide.

Did I care about metal shielding or FCC certification?  At this point, no - I just wanted something to play with.

So all the modules were either too wide to fit between the pins or I was going to be looking at some sort of oversized mounting PCB with 2.54mm SMD pin headers.

Other dev. boards in the line up that were 2.54mm pin-friendlies like Adafruit’s Bluefruit or SparkFun’s Dev. Board weren’t Pro Mini pin-compatible.

They made up a sea of different pin-out and board layouts

All-in-all, rather non-friendly to an 8-bit Pro Mini native seeking his fortune in the 32-bit land of opportunity!

So, I decided to roll my own.

Limitations

Since the nRF52832 was available in a QFN-48 package, this gave me more routing room than the 1284p.

But I’d never worked with a QFN package like that before and didn’t know whether my “skillz” were up to it.

Not one to shy away from a challenge though, I sketched out Nordic’s reference circuit schematic and began.

I opted for the extra DCDC componentry to enable some lower power operations for later experimentation.

After a rough place-and-route, the essentials fit quite nicely between my self-imposed prison of Pro Mini pins.

However, the question then became, what exactly to route out, and where to?

SWD vs. FTDI

First on the list were the SWD programming pins.

I had very limited JTAG/SWD experience coming, as I did, from the FTDI-world of the 8-bit ATmega.

So my first thought was whether there was some sort of half-way house to ease my transition.

Nordic’s SDK for the nRF52832 described a bootloader that could update the firmware of the device via UART.

That sounded ideal.

The device simply needed to be “reset” into a state in which it would patiently wait for new firmware.

SparkFun had accomplished this via Nordic’s recommended combination button press.

On the other hand, Adafruit had also added some componentry to their FTDI DTR pin to simulate the reset button press and a brief wait (~1.5s) for any new firmware on every reboot.

You could force a longer wait using the same combination button press on their board too.

I liked the idea of being able to still use my small army of FTDI programmers and their associated Fiddy’s.

As well as knowing that some project boards relied upon the position of the Pro Mini’s FTDI pins for TXD/RXD and/or VCC and GND.

So I threw two small push buttons, FTDI pins and a resistor/capacitor pair onto my fledgling 32-bit Pro Mini board.

Since sprinkling two LEDs into the mix would make identifying the bootloader state a little easier, these went on too.

I also made sure to route the SWD CLK and IO pins, since I would need access to these anyway to put the custom bootloader on in the first place.

There was no escaping learning to (re-)program in the 32-bit MCU world.

At the time, I thought J-Link Seggers were my only real option for programming/debugging.

But later went on to build a BMP out of a Blue Pill for everyday use.

(Although, I’ve since discovered some “bricked” chip states that it appears only the J-Link can recover from…)

My board real-estate was filling up fast!

NFC and ANT

[To be continued...]

Discussions