Written by Elecia White.

In Part 1, I left you with a puzzle: given the chip markings what can you tell about the BB8's internals? I've done very little reverse engineering before so this was quite a challenging.

There are a few SMD databases and the eevblog forum is a good site for package translation. Typing random numbers and letters into a search engine leads to strange, occasionally useful results. It was a try-everything sort of time (and ask anyone who might possibly know: thank you to Andrei from the Great White North, Stuart McAndrew from Down Under, and Philip Freidin of Fliptronics).

BLE Chip

Let's start on the left side with the blue box labeled CSR1010. It is a single-chip BLE (4.1) solution that includes a 16-bit microprocessor with 64k RAM and 64k flash (50k in user space). The possible interfaces include I2C, SPI, and UART. It is low power, with an idle current of about 1mA and various sleep modes under 5uA.

U5 in that picture is the STM2451. It is an I2C EEPROM (512kbit, 64K x 8bit). I found the pinout to be helpful.

The left side is connected to ground (I spent a lot of time listening to my voltmeter beep). The I2C signals (SDA and SCL) are not connected to the test points labeled I2C_SDA and I2C_SCL, they are connected to the aforementioned BLE chip. Section 6.2 of its datasheet (link above) explicitly suggests an I2C EEPROM holds the code. That seems like a safe bet. The write control was also grounded so the chip is writeable all the time. While it is likely a repository for the CSR's user code, I wonder if it is used for another purpose as well (though the CSR datasheet recommends the connection).

There is an unpopulated header next to the I2C EEPROM on U5. I initially thought this was a programming header for the EEPROM but it ohms out to the SPI test points on the other side.

That these test points do not seem to go anywhere other than the BLE chip (and the P9 connector). I suspect they program the CSR flash via the debug SPI flash. (The debug SPI pins are different from the chip's shared SPI/I2C port. The test point marked SPI connects to the BLE's special pin to enable debug SPI (pin 26). The test points are likely used with pogo pins in manufacturing to program the board.)

Main Processor

Moving along the board clockwise, there is a header that doesn't plug into anything. All of the other populated headers go down into the charging and motor control mechanics. This one has a header but notches into a cavity in the body.

As a developer, I spend a lot of time explaining why a debug port is handy, even in manufacturing. I might have salivated a little on pins marked RX and TX. These aren't a debug port (or aren't only a debug port), they connect the BLE chip to the other processor on the board.

The STM32F373 is a burly processor: 72MHz Cortex-M4, floating point unit, 32k RAM, up to 256k flash. It has plenty of IOs even in the 48 pin package on the board. There is even a memory protection unit (MPU). You could do a lot with that processor. I wonder what they are doing.

The P6 in the picture is another unpopulated connector. Careful Ohm'ng out under a microscope shows the processor pin connections to be a standard Serial wire JTAG debug port (SWJ-DP). The temptation to plug in my ST-Link is high.

Inertial Measurement Unit (IMU)

Moving along on the hardware connections, the STM processor does connect to the I2C test points. And those test points connect to U11 with pin markings “134 A1426 095”.

This chip was my nemesis. It was over near the BLE chip. The pins didn't seem to go anywhere (and they were stubby so difficult to connect with). The package was odd: 7 pins on each long side and 1 pin on each short side). By laborious and uncertain process of elimination, I knew it had to be an inertial sensor, probably accelerometers and gyros (6 DOF). (A 9DOF with magnetometers was a possibility as well.)

It is the Bosch BMI055, a small, low power 6DOF inertial sensor. At first, I thought this was the BNO055 which has the fusion algorithm in the chip (the Adafruit breakout board and calibration instructions are excellent). Sadly, this is a sensor-only package so the STM32 must be running a sensor fusion algorithm (which is why they need floating point hardware). Nonetheless, I recommend reading those calibration instructions because this sensor won't be nearly as effective without them.

One of the issues you must solve when working with inertial sensors is the problem of inertial frame: where are you with respect to the sensor? For BB8, this is an especially difficult problem, he's been rolling around and you can't see into the shell to figure out which way the sensor is mounted. Which way is forward? For you, probably it is the direction you are facing. Intuitively, whichever why BB8's head is facing is forward. However, BB8's head may not be on (remember it has no real function to the robot).

The solution is to put a blue LED on the edge of the board (D1 in the picture of the STM32). In the application, there is a feature to spin BB8 (in place), pointing the blue LED toward you, thereby (grossly) aligning your inertial frames and letting you drive the robot about. This blue LED is a common Sphero technique and is called the “taillight”.

There are two other LEDs on the board, RGB LEDs (like these) that are in sync and PWM controlled from the main processor. These indicate collision detection, BLE connection and loss, and user feedback.

Motor Driver

Also connected to the main processor is the motor driver. I believe it is a Toshiba TB6552FNG

I was adamantly certain that the motors were steppers. There are 6 pins going to each motor.  One of the motor connectors is in the picture above, the other is 180 degrees away on the round board.

The pins going to each motor are labeled:

Mx1        Ex1

GND      PWR

Ex2        Mx2

Where x is L or R depending on left or right. It only takes two pins to drive a DC, so these must be stepper motors, right? No. My simple rule of thumb doesn't work when I fail think it all the way through. This is a consumer product and doesn't need to be precise. It makes sense to use the IMU for feedback as the system doesn't care about accuracy, only that it is spinning at about the right speed. Looking at the driver, though, only two pins drive each motor. (Also, for those of you who want to know about my inability to read the obvious, the chip's datasheet title is "DUAL-BRIDGE DRIVER IC FOR DC MOTORS".)

The M lines connect to the motor driver. The E lines connect to the STM processor. It would make sense that those be feedback. E for encoder makes sense; two lines would indicate a quadrature encoder. That would be interesting on a scope (but I'm pulling that out for next week's post so I'll leave it at speculation for now).

Power Subsystem

Two LiPo batteries are connected in serial. This gives a higher voltage potential, making it easier to run the motors. For efficiency, I suspect the 3.3V that runs the main processor, BLE, and inertial chips is taken from the midpoint. This causes an uneven load on the batteries (they tell you not to do that to batteries in serial because it is BAD but with the tiny draw of those components compared to the huge draw of the motors, well, it is how I would do it.

The other parts of the power subsystem include a Li-ion charge controller, a 3.3V regulator (marked JA033, found by Stuart McAndrew), another voltage regulator (package completely unmarked but Philip Freidin identified it from the passives on the back, it likely has something to do with the inductive charge), and dual op amp (UTC LM358G).

Hardware Summary

Going back to the board view, I can swap out the chip package marking for their functions.

From a sea of parts, the board begins to form into a recognizable system.

The next step is to look at this from a software perspective: What are the two processors saying to each other? What is the feedback from the motors? What can I find out about the connection to the inertial sensor? And is the BLE interface easy to look at? Is it as programmable as the Sphero SPRK?

All of these questions will be addressed soon (or hit the link above to see the related post).