If you remember previously, I'd posted a picture that had the pins marked on it. This is really handy reference, as it makes connections plain. From reading the datasheet, there's three pins that are "interesting" at this point. What's really handy is that they're next to each other!
These pins are SDI (Data in), SCK (Clock) and !SEL (Chip select). If you've played with the SPI bus at any point, you'll be fairly familiar with this. If not, then this wikipedia article might be helpful to read. So, the plan is to connect something that can sniff the SPI bus across these pins (and power!). I could use a logic analyser to do this, but the Bus Pirate has a useful SPI sniffer, and this may work out better. Before we can do that, there's a little bit of soldering to do. I've wired up some ribbon cable for the three SPI bus pins as well as ground. I've also attached two pins (FSK and interrupt) for attempting to decode the transmitted data at a later stage. First, a close up to see what I've connected to - you can cross reference it to the pinout above.
Zoom out a bit, and we can see the Bus Pirate connected up and ready to interrogate the Dev Board.
I'm using the Bus Pirate's 3.3V power supply (the white clip) to drive the board too, as this saves me having to find a separate power supply.This can be turned on and off from the serial console the Bus Pirate provides. Now, to make the Bus Pirate talk SPI, I have to choose the SPI mode. There's a bunch of configuration that's not relevant to me at this stage, as I'm sniffing rather than driving an SPI bus. Once the Bus Pirate is in SPI mode, I can turn the power supplies on (W), and invoke the sniffer macro (1). One thing I have done is hold the Dev Board in reset by shorting the reset pin to ground on the 10 pin connector. This makes it easy to start, as the sniffer macro doesn't let me turn the power on/off. To change the power, I have to exit the sniffer. So, holding the device in reset, the next step is to see what comes out!
Success! We've captured the initial bust that is sent out. However, you need to know a little bit about how to interpret the output otherwise it's not very useful. SPI is a bi-directional bus, so when you transmit a bit you also receive a bit. The Bus Pirate prints the master to slave data followed by the slave to master data in brackets after. As there isn't any slave to master data, it's always (0x00) in this case. The open square bracket "[" indicates that the chip has been selected, and the close square bracket "]" indicates the chip has been deselected.
So, after removing the slave to master data, and grouping data into words (as that's what the chip expects) you can see the following messages are being sent. I've put a line break in where the chip is deselected and then reselected to add clarity.
[CC00 88F0 C857 D240 A634 C220 C001]
[CC00 88F0 C857 D240 A634 C220 C001]
[C039]
[C001 C400]
What happens if we allow the device to run for a little bit longer? Do we get different messages?
Well, this is the data that comes out:
[CC00 88F0 C857 D240 A634 C220 C001]
[CC00 88F0 C857 D240 A634 C220 C001]
[C039]
[C001 C400]
[CC00 88F0 C857 D240 A634 C220 C001]
[C039]
[C001 C400]
[CC00 88F0 C857 D240 A634 C220 C001]
[CC00 88F0 C857 D240 A634 C220 C001]
[C039]
[C001 C400]
It looks like it just repeats itself. One interesting thing to note is that sometimes the configuration message (starts CC00 88F0) is repeated. I've no idea why this is. If we spent a little time breaking down what happens at what point in time we get the following patterns:
| Initialisation | [CC00 88F0 C857 D240 A634 C220 C001] |
| Transmit data | [C039] |
| Power down | [C001 C400] |
Now, you may note that this is just the configuration and commands for the transmitter module. There isn't actually any of the transmitted data. The reason for this is that the data is present on a different pin, using a different technique for sending it. We'll look at that next time!
Next Part 3
No comments:
Post a Comment