This article continues our exploration of the Airwheel X3. Last time, we disassembled the beast and took a peek around. This time, we’ll break out the soldering iron and get to hackin’!
Unknown (ahem) Target – Research and Sleuthin’
First – how do we even start? We have no f*cking clue what the micro is, and the topmark has been hopelessly annihilated! Well not really completely removed, but let’s ignore that also for now.
Whatever will we do? After all that obfuscation, there’s no way the developer would leave a live JTAG port conveniently pinned out and labelled, is there?
Well yes. Yes, that’s exactly what has happened.
If you’ve seen the airwheel PCB, you have seen the main header connection down at the bottom. There are a couple of conspicuously empty headers, and they just happened to bemarked: 3.3 SWCLK SWD GND
Here’s a pic that’s better than our own – we found it online here.
Hmm. A little LMGTFY tells us that this is none other than the standard ST-Link connector. So using our head grease trick, the ST-Link port evidence, and the fact that you can see the ST logo through the hot glue in above picture makes us suspect that the micro is an ST chip. Wow! See what we did there?
So let’s hook it up! We chose to pipe our port out the side of the body, because who knows – maybe it’s completely feasible to debug arm code while carrying a laptop and riding an airwheel. Charles would do it. As far as connections go, you can safely ditch the 3.3V line and only connect the other 3 lines: SWCLK, SWD, and GND. That’s all that’s needed when operating with an externally (USB) powered ST-Link anyway.
We chose to use a bit of ribbon cable to bring the port out to a standard 0.1″ header socket stuck into a little dremelled slot in the side of the case. Le port hack is shown below.
And the internal connection is just as simple – ribbon cable from the PCB headers over to the socket. Plus copious amounts of hot glue to keep it all in place and quasi-splash proof. Protip – Cover that debug port with tape to keep dirt and moisture out!
Interlude – Calibration header!
While we’re in here messing about, we might as well add a set of header pins between the SP and GND connections to allow us to start the calibration routine. Here is a pic of the header in relation to the debug cable.
The calibration routine is started by powering up with SP shorted to GND. With our little 2-pin header here, we just stick on the header clip and fire it up. The control board side of the unit should be standing straight up for calibration, although it doesn’t need to be assembled. So feel free to cal with the shell open, as long as the board is in the proper upright position.
The calibration routine takes gyroscope data as well as motor data during a short test. Upon power up, the wheel will spin slowly forwards over 3 full rotations, then reverse over 3 full rotations. Then the data is stored and the hellish beep alerts you that cal is done.
You should never need to enter cal unless you have seriously borked the unit. And if you have, you probably know enough to get yourself out of the hole you’ve dug. So think of the calibration as a fun piece of trivia you can set aside for never.
Back to the ST-Link Port
We’re not done identifying out the micro, so let’s get back to that! We’ve found the easiest way to debug is to put the entire unit on it’s side when powering up. It will immediately fault and give an annoying steady beep, but the motor won’t be running which helps a great deal. Alternatively, just pull the 3 motor phases but that seems like a lot of work.
Now fire up your ST-Link adapter, and here’s what you’ll get.
Lookie here – A part ID! So the mystery micro is an STM32F103C8T6, the same device as in the real and homebrew ST-Link V2, or the one that acts as an ST-Link on the Value Line Development board, as well as copious numbers of low-cost development boards like this one and this one.
Remind us sometime to tell you how to turn one of those cheapo dev boards into a spare ST-Link…
But for now – we’ve got it! But maybe not. The flash is read protected, which will severely hamper our debuggings and hackings. Makes sense, but based on the number of clones out there we suspect that the read protection is either incredibly easy to bypass, or there is a very active market for “Production Data” of every new product manufactured in Shenzhen. Either seems just as likely as the other, so drop us a line if you know which is which.
So it seems that this might be a build-from scratch effort. Time to dust off those ST app notes on driving BLDC’s!
As a parting gift, we’ll provide you with a “No they didn’t!” moment from the lab here.