Avian’s Blog

Thanks to my previous posts about Amazon Kindle, I have another broken specimen on my desk now. This one seems to have experienced an interesting battery failure.

Kindle's battery has 4 terminals: ground, a positive terminal for power and SDA and SCL pins for I²C communication with the integrated battery management circuit. On a normal battery, the positive terminal is around 3.7 V above ground, depending on the charge level of the Li-ion cell and the I²C lines are on ground level, because they need external pull-ups.

This broken battery however has the positive terminal at 0 V compared to ground terminal while the I²C pins are at -2.5 V. I can't imagine what kind of failure mode could cause pins to go lower than ground, unless the polarity of the cell got reversed somehow. I don't see any way how a failure in the battery management circuit or a loose connection somewhere could cause such readings. I'm pretty sure it's not an artifact of my multimeter either, because the battery can draw some milliamps of current from the ground to one of the I²C pins. For the record, this looks like an original 1830 mAh battery. Date of manufacture is April 2011 and type is 170-1032-01 Rev. A.

The master I²C interface on the Kindle wasn't damaged though, because it boots and reads out battery state just fine when attached to a different battery. There does seem to be a problem with bad a connection somewhere on the motherboard, because it crashes if I lightly knock on the CPU package. Possibly a hairline crack in some solder joint. But that's a topic for some other time.

Experimental radio equipment on VESNA can be used for more than spectrum sensing. Radio boards based on Texas Instruments CC2500 and CC1101 transceivers can also be used for packet transmission and reception and, perhaps somewhat surprisingly, also as flexible signal generators. These can be used in experiments when you want for instance to introduce a controlled interference in some system or to check if your spectrum sensor is working correctly.

Usually when I'm talking with people about what our hardware is capable of the conversation often starts with amazement at how small the radio part is and then inevitably turns to the question whether VESNA has a software defined radio. I have to answer no, it doesn't, and then there's usually an awkward silence because that seems like a dead-end for any serious research work these days.

True, these transceivers don't provide software access to the undemodulated baseband samples (like for instance USRP does). However they are still amazingly flexible. They offer plenty of reconfigurability and, after you get to know some of their quirks, can be adapted for a lot of weird use cases without hardware changes. If you skip the various high-level digital parts of the chip for proprietary packet format handling there's a flexible front-end in there that allows you to choose between a handful of frequency, amplitude and phase modulators and several options for channel filters and such.

The closest you can come to software defined radio is a transparent continuous transmit mode where you can feed the transceiver arbitrary binary data from the microcontroller and it will simply get modulated and fed into the antenna. There is a catch though, since the chips offer at most 2-bit quantization of the baseband signal before modulation (they were designed for simple digital transmissions after all). This means that you have to get creative if you want to approximate an analog modulation and be ready for plenty of quantization noise.

This is how it looks like on a spectrum analyzer when you run a direct digital synthesis algorithm on the microcontroller that generates a baseband sawtooth frequency sweep and use the amplitude modulator to up-convert it to 2.4 GHz:

(Click to watch RF signal synthesis using VESNA video)

Using delta-sigma modulation you can approximate arbitrary waveforms in this way. For instance, you can make a passable simulation of an (analog) wireless microphone transmission using a 4-FSK modulator in CC1101 tuned into the UHF band.

Of course, setting this up takes more work than popping a few blocks into GNU Radio Companion and part of my job is to make it more accessible to people using VESNA and our VESNA-based testbeds. If you're interested in such signal generation using Texas Instruments CC series, some platform-independent code capable of doing this should start hitting the vesna-spectrum-sensor repository on GitHub in the next few weeks.

Multilib is a mechanism in GCC for handling multiple binary versions of a single library that have been compiled using different compiler options. This is useful for instance when compiler options affect the ABI and the linker has to choose the correct library version to link your program with. ARM architecture with its multitude of ABIs and floating point unit options is a prime example where this comes in handy.

Multilib works by mapping compiler command-line options to directories where libraries can be found. For instance, GCC compiled with my fork of summon-arm-toolchain says this about its multilib support:

$ arm-none-eabi-gcc -print-multi-lib
.;
thumb;@mthumb
fpu;@mfloat-abi=hard

What this says is that binaries compiled with -mthumb will be linked with libraries that appear under thumb/ and binaries with -mfloat-abi=hard will use libraries under fpu/ relative to the usual library search path.

However:

$ arm-none-eabi-gcc -print-multi-directory -mthumb
thumb
$ arm-none-eabi-gcc -print-multi-directory -mfloat-abi=hard
.

While thumb option seems to work as expected, the hardware-float libraries don't appear to be used. Why is that?

It turns out that multilib is somewhat smarter than what the documentation and -print-multi-lib would lead you to believe. It doesn't just check the options that you give GCC explicitly on the command line but also their default values.

It seems that -print-multi-lib assumes built-in default values for these options. It believes that fpu/ versions have been compiled using ARM, not thumb mode. But since -marm is default, it doesn't print it out explicitly.

However, this GCC has been compiled using --with-mode=thumb, which changes the default to -mthumb:

$ arm-none-eabi-gcc -v
Using built-in specs.
COLLECT_GCC=arm-none-eabi-gcc
COLLECT_LTO_WRAPPER=/home/avian/local/libexec/gcc/arm-none-eabi/4.6.3/lto-wrapper
Target: arm-none-eabi
Configured with: ../gcc-4.6.3/configure --target=arm-none-eabi
--prefix=/home/avian/local --enable-interwork --enable-multilib --with-newlib
--disable-shared --with-gnu-as --with-gnu-ld --disable-nls --disable-werror
--with-system-zlib --with-arch=armv7-m --with-mode=thumb --with-float=soft
Thread model: single
gcc version 4.6.3 (GCC)

Multilib is smart enough to know that libraries under fpu/ won't work with code compiled with -mthumb and falls back to the default directory and hopes for the best. So, to get the compiler to use libraries under fpu/, you have to explicitly set it to ARM mode:

$ arm-none-eabi-gcc -print-multi-directory -marm -mfloat-abi=hard
fpu

By the way, the combinations of options and directory names printed out by -print-multi-lib are set using MULTILIB_OPTIONS and friends in gcc/config/arm/t-arm-elf in the GCC source tree.

Here's a small addendum to my previous list of lessons regarding easy debugability of microcontroller boards.

It's not a bad idea to pay a bit of extra attention to the connectors that will be used when developing and debugging software. It's likely these will see much more use than any other connector on the board, especially if the board is also meant for teaching or research like VESNA.

The first concern is that it should be hard to connect it in a wrong way. IDC and similar pin header connectors are popular for JTAG. Use a male part that has a shroud so that it's impossible to connect it when displaced by a pin or turned 180 degrees. That might sound obvious, but when you're debugging that tricky race condition and switching the debugger between three systems on your table late in the evening, the last thing you need is a burned out board because of a misplaced connector.

The other thing that is also worth considering is the life time of the connector itself. While the life time of the part on the board might not be problematic, the part that stays with the developer can be. For VESNA one of the most common reasons to make a trip to the soldering station is a torn wire in the connector for the serial debug console. We use something similar to the Berg connector and that one doesn't really take many connect-disconnect cycles before either wires get torn out or little springs break and the metal part falls out of the plastic housing. It's not always obvious that has happened and again it's a pain to realize after a long debugging session that the reason a board is talking garbage is not due to a bug you're trying to catch but rather due to a broken ground line in your debug console.