Amazon Dash and other STM32 ARM Adventures

I dumped the bit banged I2S data to the Dash's serial console and logged it to a file. After a few hours of waiting, I was able to whip up a small Node.js program to convert the ASCII into a binary blob. Imported it into Audacity and got this sweet looking waveform. Too bad it sounds like static.

Here's the code.

var fs = require('fs');
var convertHex = require('convert-hex');
var tokenizer = require('tokenizer');

var t = new tokenizer();
t.addRule(/^0x[0-9A-Fa-f]+$/, 'half');
t.addRule(/^\w+$/, 'junk');
t.addRule(/^\s+$/, 'whitespace');
t.addRule(/^.$/, 'whitespace');

var pcm = fs.createWriteStream('pcm.raw');

var bytes = [];
t.on('token', function(token, type) {
	if (type == 'half') {
            if (token.content.length == 6) {
	        var b = convertHex.hexToBytes(token.content);
		bytes.push(b[0], b[1]);
            }
	}
});

t.write(fs.readFileSync('../audio.log', { encoding: 'utf8' }));

t.on('data', function() { });

t.on('error', function(error) {
	console.log(error);
	pcm.write(new Buffer(bytes));
	pcm.end();
});

t.on('end', function() {
	console.log("DONE");
	pcm.write(new Buffer(bytes));
	pcm.end();
});

t.end();

I've spent the past couple of nights trying to piece together the code necessary to get the microphone running. I don't know much about clocks, PLLs, DMA, or even I2S for that matter, so there's been a lot of head scratching and hand waving about which code goes where.

The STM32F2 code base in the WICED SDK is missing a platform_i2s.c driver. I lifted the STM32F4's platform_i2s.c and deleted the stuff that confused me. I've written a stubby ADMP441 driver to setup the right GPIO before calling into my new platform_i2s.c where it will set up the I2S block and DMA channels.

I've been struggling to get DMA to generate an interrupt on completion of a block of microphone data, so I've turned off that code and focused instead on trying to get at the data by waiting for an SPI RX interrupt and effectively polling the bus for data. I've only gotten zeroes or a hung process, so I was suspecting that either the clock/PLL set up is wrong or the microphone just isn't enabled.

I don't own a logic analyzer (actually I ordered a cheapy off eBay today) so I can't verify data on the Dash's exposed CLK and WS pins are waveforms or just constant voltage. I guess once the logic analyzer arrives in the mail, I'll be able to use a hot air gun to remove the microphone and insert my probes in between to help debug the DMA problems.

Anyway, today I managed to get actual data from the I2S SPI port.

I don't know if that's actual PCM data or not, but it's definitely better than a bunch of nothing.

I've been working to coerce the Amazon Dash's I2S microphone into generating some IRQs with the WICED SDK, but no luck so far.

I've pulled CHIP EN (PC1) high and can see it stay high on my DMM. I've turned on the I2S PLL via the stm32f2xx_spi.c library calls and I get 1.5V measured on SCK (PB10) - without a scope, I'm hoping this is a waveform and not constant voltage.

Here's a staging patch on my GitHub repo. Much of the code is copied and pasted from the STM32F4xx folder in the WICED SDK.

I put up a GitHub repository here: https://github.com/gtalusan/redash. This has instructions to build up a firmware and deploy it the Amazon Dash with an ST-Link V2.

I was trying to figure out why I could only successfully write and erase a sector of my Dash's flash once. On the left is the data sheet for the M25P16, the middle are the SPI commands that Broadcom's WICED SDK uses to erase a sector and the entire chip, and on the right is the data sheet for the SST25VF016B.

Nothing lines up!

I managed to enable SPI Flash for Dashes with Micron M25P16 chips. 0x202015 is the magic JEDEC number that the M25P16 returns when it's asked for its bus identification. Sweet!

I've mapped the platform_gpio_pins table from Cottonelle.bin to some readable source code. After cross referencing it with maximus64's work, this is what we've got:

We have some potential candidates for the SPI GPIO now. The WICED SDK is kind of fast and loose with how GPIO are declared and referenced in the other data structures, so I might have to due a bit more byte sniffing to figure out if I can glean more information about platform_spi_mapping_t and wiced_spi_device_t.

Here I aligned some modified GPIO pin declarations on the left and mapped them over to the virgin Cottonelle.bin. The purple underline is where I suspect the array ends.. the GPIO_TypeDef * is out of range, I think.

On the left, we have a sample application from WiCED SDK 2.4.1 binary diff'd against itself after changing a single byte so we can find our way to the GPIO table.

In the middle, the example application.

On the right, a similar dump from Cottonelle.bin from dekuNukem's firmware dump...

Now to do some mapping...

Time to back up the flash. I was trying to use st-flash, OpenOCD, pystlink, and st-util+gdb to get a good dump of the flash memory in case I wanted to go back and play with Amazon's software. The dumps were packed with nil-bytes, so there's probably some read protection going on.

OpenOCD's manual has a nice command for unlocking the flash :

stm32f2 unlock 0

This generates a buttload of output:

Debug: 19140 55145 target.c:2226 target_read_u32(): address: 0x40023c0c, value: 0x00010000
Debug: 19141 55145 stm32f2x.c:219 stm32x_wait_status_busy(): status: 0x10000
Debug: 19142 55146 hla_target.c:752 adapter_read_memory(): adapter_read_memory 0x40023c0c 4 1
Debug: 19143 55148 target.c:2226 target_read_u32(): address: 0x40023c0c, value: 0x00010000
Debug: 19144 55148 stm32f2x.c:219 stm32x_wait_status_busy(): status: 0x10000
Debug: 19145 55149 hla_target.c:752 adapter_read_memory(): adapter_read_memory 0x40023c0c 4 1
Debug: 19146 55150 target.c:2226 target_read_u32(): address: 0x40023c0c, value: 0x00010000
Debug: 19147 55150 stm32f2x.c:219 stm32x_wait_status_busy(): status: 0x10000
Debug: 19148 55151 hla_target.c:752 adapter_read_memory(): adapter_read_memory 0x40023c0c 4 1
Debug: 19149 55152 target.c:2226 target_read_u32(): address: 0x40023c0c, value: 0x00010000
Debug: 19150 55152 stm32f2x.c:219 stm32x_wait_status_busy(): status: 0x10000
Debug: 19151 55153 hla_target.c:752 adapter_read_memory(): adapter_read_memory 0x40023c0c 4 1
Debug: 19152 55154 target.c:2226 target_read_u32(): address: 0x40023c0c, value: 0x00010000
Debug: 19153 55154 stm32f2x.c:219 stm32x_wait_status_busy(): status: 0x10000

.. and then I was left with an empty flash that's perfectly dump-able without error. Doh.