Every autumn deserves its pumpkin hacking projects. This Halloween, our pumpkin comes with a horror story. It began last year in early November. All the Halloween decorations were on clearance, and I found a plastic jack-o-lantern bucket for 15 cents. On first sight, I knew I must remote control it. Over the months following, the project came to my work bench now and then. I did simple things like cutting holes for the wheels, and mounted some of the mechanical things. Cutting the plastic with a utility knife was super easy.
Around the end of September this year, I sifted through my scavenged collection of electronics and formulated a plan. I decided on some Bluetooth devices because I wanted to explore that technology. The particular board in my stockpile was discarded from the product development process (insert eerie sound effects here). I didn't know its history. I didn't know if it had the standard released bootloader. I didn't even know if it worked. I was driven to make this pumpkin roll, so I chose to go forward with it. Our SparkFun nRF52832 breakout board would provide the brains and radio for the operation. The new Qwiic Motor Driver would control the drivetrain. Last, a SparkFun USB LiPoly Charger would provide battery management for the whole system.
Confident in my success, I walked over to marketing and asked to write a blog about this project ( tense orchestra music), and we set the blog date near Halloween. It was only some wiring and software development – what could go wrong?
Drama and jokes aside, I’m bummed I don’t have a pumpkin to show today. My job here is IT, not EE, so this is my free time hobby. I have a number of other things that consume that free time, such as my two young children. Here are the high-level things that went wrong with the pumpkin.
IDE
PlatformIO
My first holdup was getting any code to upload to the Nordic board. I recently started using PlatformIO and it’s awesome. It has the features of Visual Studio Code (or Atom) and a huge number of board and library definitions built in. The SparkFun nRF52832 breakout board is not explicitly in the list of supported boards. If I understand this GitHub issue, a breakout board is close enough to a bare chip to not merit its own named board definition.
That hindered my progress in my first-choice IDE. I’m certain I could get it to work with enough time, but I was already so close to my deadline so I chose to try something else.
Segger Embedded Studio
My second choice was to follow Nordic Semiconductor’s recommendation: Segger Embedded Studio with the Nordic SDK. SES is focused on ARM chipsets, and has a workflow that resembles Visual Studio. Nordic has built their SDK to integrate into SES. This combo provides the best capability for working with Nordic SOCs on OS X. I spent a couple hours following the instructions, trying to troubleshoot why SES didn’t find the SDK. I’ve set up IDEs with SDKs before, and I know issues such as this can take a huge amount of time to fix. I stopped there. The IDE looks like it’s great for ARM development, so I look forward to getting back in there another time.
Arduino
I fell back on the old familiar. SparkFun has a board definition for our nRF52832 breakout board in Arduino, so that situation got me out of my standstill. On to software development!
Bluetooth
Bluetooth is a large topic; I didn’t know quite how large until I dove in. The process of developing firmware would take longer than expected. A Bluetooth network must have a central node and the rest are peripheral nodes. Each node specifies what it can do in one or more profiles. A profile can have multiple services. Each service can have multiple characteristics. A characteristic has a value (usually shown in hex) with one or more permissions assigned to it. Each of those pieces has a UUID associated to keep them all straight. There are standard profiles with reserved UUIDs for things like mouse, keyboard and audio devices.
The task of inventing the Pumpkin Control Profile didn’t pan out as I hoped. I also tried to find a profile to use with a ready-made phone app (more on that below). I resorted to a UART profile I found in the examples of the BLEPeripheral library.
The BLEPeripheral library does a great job making some of all that complexity more accessible. It even forced me to learn how to spell peripheral. However, it does not enable the user to create a central node. I’m bound to using a phone or computer to act as my central node until I can determine how to get center functionality in an ARM chip.
iOS Apps
I tried two iOS apps with joysticks for Bluetooth. Each of them required some specific hardware. I assume they’re looking for the UUIDs or device names of the product they support, and I tried to get information I needed to fake them out. Maybe the info is out there, or I’m overthinking it. Either way, the joystick on the phone didn’t happen. Nordic has some awesome mobile apps for their products. The nRF Toolbox app, among other functions, has a UART feature with assignable buttons. I gave each button a couple of ASCII characters that correspond to instructions for the two motors in the pumpkin firmware.
Hardware
Poorly planned connector placement
Disconnectable assemblies are my favorite. Whenever possible, my projects have pin headers and other connectors wherever the solder joints occur. This makes it possible to untangle the spaghetti.
The buttons for this board are smallish, and they are necessary to put the device in DFU mode. That is not a huge problem, but I chose to put all of the connections to the board on the same side as the buttons - not good. There is now a tiny fence around it, and my finger barely fits inside. Uploading to the pumpkin meant I had to find the button by touch and hold it while plugging in the FTDI cable. I spent most of my time developing on another of the same board with no such impediments.
I2C
The I2C didn’t seem to work for me at the start. After plenty of trial and error, I noticed a highly valuable comment from Bobby on our tutorial page. Basically, you have to define in Arduino the SDA and SCL pins you want to use. After a couple of hours, I thought I was finally ready, and no - the devices didn’t connect. I tested the motor driver with RedBoard and Qwiic shield, so I know it works. This is the final problem. I’d have a drivable pumpkin if I could get them to talk. It’s fixable, but not in time for this blog post.
Defeat vs Failure
If you’ve made it this far into the horror story, you’ve reached the unresolved ending. Will the pumpkin make it out alive? Will the gremlins kill it? It’s also the most important part of this story. I love a podcast called Making It. It’s three YouTubers that converse about making physical things for content on their channel. One of the recurring themes in the podcast is how to deal with not succeeding. When you make a thing, it may not turn out as expected. That’s the situation I’m in, so I get this following bit of inspiration from the podcast.
As of this writing, I’m defeated. The pumpkin doesn’t work, but to quote Thomas Eddison:
I have not failed, I have just found ten thousand ways that won’t make a remote control pumpkin.
If I stop now, I will fail. However, I’m going to get this pumpkin rolling. Since the problem is the I2C connection, I can either fix it or replace it with a simpler motor driver. I’m also keeping a positive attitude about all the external things I used in this project. I won’t blame the IDE or the manufacturers when it was clearly my preparation and decisions that led me here.
I may be defeated at the time of this post, but I won’t fail. Watch the comments for updates on this pumpkin. While you’re down there, misery loves company. I’d love to hear your horror stories too.
Thank you so much for sharing this story. I feel we can learn so much as makers be hearing the stories of others. Especially stories that are not successful. It is rare that we share those stories, but I feel they are highly valuable to me. Thanks!
I find it encouraging when others do this. I sorta wish I had finished the thing before the deadline, but since I didn't, I tried to help others with this story.
I have tried to do something similar with these Nordic nRF52832 chips (just we had a Chinese module instead). Here are a few observations:
Don't waste your time with BLEPeripheral library and Arduino on these boards. Except for extremely basic things it just does not work, it requires hacks to get the right version of the Nordic "softdevice" binary blob, it works only with a very old "softdevice" version, so a lot of functionality either does not work at all or is buggy (such as bonding). The API is easy to use and most of the Bluetooth LE complexity is swept under the rug but what good is that if the device is failing randomly.
The Nordic SDK is excellent and has very good documentation. However, expect steep learning curve! The examples and documentation assume that you know how BLE works already, so it is very advisable to read up something first or you will get overwhelmed quickly. On the other hand, I have managed to get both serial port to work (BLE doesn't have "profiles", so don't look for those. There is the GATT protocol and everything works on top of that) and also a HID device (HID over GATT), persistent bonding with automatic reconnections, etc. Haven't tried to implement a central role but the SDK has examples of it.
Segger Embedded Studio - not worth wasting time on, IMO, unless you are working on that platform already (and are paying for it). PlatformIO or Visual Studio Code will do the same service for you, even if you are using the Nordic SDK - the SDK is very simple to integrate, you literally have to add all files from the SDK (except for the examples) to your build ... Just use the makefiles shipped with the examples as the starting point.
PlatformIO - the problem with PlatformIO and nRF52 series is a rather boneheaded way they have added the support. Instead of making it work with any sort of SWD debugger that works with ARM they have for whatever reason specified only certain debuggers for certain boards and that's it. It won't allow you to program or debug the device with anything else. If you have a bare bones SoC, then likely it is only CMSIS-DAP or J-Link. I didn't have neither ... You can either flash the device from command line using OpenOCD and any SWD dongle that OpenOCD supports (PlatformIO uses OpenOCD internally anyway) or buy one of the cheap Chinese STLink clones and reflash it with CMSIS-DAP firmware (that's what I have done - after replacing the dodgy STM32F103 in it).
However, you will want CMSIS-DAP or the (expensive) J-link, because many of these nRF52 series modules come with the debug port (DAP) locked down for whatever reason by the module manufacturer. So you can't even clear the flash, OpenOCD will report a weird error and refuse to talk to the chip. The only dongles with which it is possible to issue the OpenOCD DAP commands to unlock it are CMSIS-DAP and J-link. STLink will flash the board but if you can't unlock the debug port first it is of no use (but you can use it to flash/debug an already unlocked device).
Debugging - if you are using the softdevice (required for BLE and ANT, not needed if you are using shockburst, i.e. the protocol compatible with the older popular nRF24L01+ modules), then debugging is a pain. It is an RTOS running asynchronously and if you stop on a breakpoint anywhere, the internal timers used for scheduling events, such as sending packets on the radio, will time out and cause a crash if you attempt to resume from it.
Peripherals - nRF52 is weird. It has a ton of peripherals but most are very tailored towards BLE and the various radio-related functions (such as cryptography, checksums, etc.). The rest is both quite basic (compared to normal ARM MCUs such as NXP's or STM32s or even AVRs or PICs) and has quite unusual API. Instead of setting registers you send and react to events, almost every peripheral could be switched to almost every pin ... It is an interesting device and takes a while to grok, to say the least.
nRF52 is wonderful for battery life - even at full blast, busy advertising and running an ADC it draws <10mA. While sleeping the power draw is down in tens of uA ...
Thanks. That's a ton of good info. I suspect you just saved me a bunch of time by describing why the BLEPeripheral library is not the best. I really appreciate this comment.
Welcome! Sadly the BLEPeripheral lib could really use some development love and possibly a redesign to support more features of these Nordic SoCs.
I've been doing electronics since the mid-1960s, and computers since a few weeks after Neil Armstrong took his "one small step". I've had a LOT of unsuccessful attempts at things since then. (Speaking of which, NASA did several unsuccessful things along the way to get man to the moon.)
I like to think of it as my projects "evolving". Once I decide on a goal, I'll decide on a way to get there. I'd built up a box to record indoor temperature once an hour (to a "private" web site) so I could know that the heating/air conditioning was still working and the house had power. I wanted to add some more sensors (e.g., an outside air temperature sensor), and it was clear that they'd have to have some sort of wireless link. When I started on this part, the "obvious" way was to use the (now obsolete) RFM-12B module, but my "box" was based on a Beagle Bone Black and I couldn't get the interface software to work. I eventually decided to put Arduino Pro-Minis at both ends to "talk" to the RFM-12Bs, and had gotten the Pro-Mini to talk to the BBB via I2C, and initiate the RFM-12B, but when I tried to transmit to the other RFM-12B, the near-end would lock up. After a few interruptions in working on it, I eventually eliminated the RFM-12Bs and Pro-Minis and switched to using an ESP-8266 on the far end, A few minutes ago I was able to note that the outside temperature of my home in the Phoenix area is about 10 degrees lower than what the outside temperature is here in Connecticut (the sun had just come up in AZ, so it will soon warm up and get back to "normal" of being warmer than CT).
BTW, I've found that when trying to do I2C on a new-to-me processor, first try to talk to something you've done successfully on another processor (like a temperature sensor). Also, my first venture into I2C several years ago was adding something on a second I2C port to someone else's design. Finally tracked down that the reason the second port wasn't working was because I hadn't put in the pull-up resistors. (Most of the "break-out boards" include them.)
One last point: "Mother nature" does a LOT of experimenting too -- remember that 99% of all species that have ever existed on this planet are extinct, meaning that you are the end product of billions of years of "trial and error".
Thanks for sharing your story. I love that you have monitored your house across the country.