So I wrote last week about getting UART working on the MSP430G2533 but having major problems with the SPI interface... I was so frustrated that I caved in and purchased a Salae Logic analyzer. It finally arrived today, and I had a chance to test it.
|Salae Logic in action!|
As soon as I opened the box, I connected it to sniff the SPI lines between my msp430 and cc2500 radio. It took me maybe 10-15 minutes to set up everything, including the Salae software to decode SPI on the fly. I ran my radio-setup code and observed the logic output. It seemed like something was happening, but it wasn't quite working.
|First capture with msp430g2533|
To get a better idea as to what it should look like, I connected my msp430g2452, which had a working SPI link with the radio. The first thing I noticed was an error saying that the clock polarity was inverted. Aha! So the SPI clock on the 2533 was low when idle, while the specification says it's supposed to be high.So I went into the datasheet and figured out how to fix the clock problem.
|'Correct' capture with the msp430g2452|
I tried it again and, not surprisingly, it failed. Looking more carefully at the MISO/MOSI lines, I realized that they were backwards! Turns out that the SPI IO pins do not match between the msp4302533 and the 2452. I swapped two wires and everything started working!
While I was really happy I fixed the problem, this means that my previously mentioned PCB will only work with one of the two devices. My plan is to use the more expensive 2533 as a PC-to-radio bridge, since it has both a hardware UART to talk to the pc and hardware SPI to talk to the radio. The cheaper 2452 only has one SPI to use the radio.
|Launchpad with cc2500 Radio and Salae logic|
In the end, I'm still happy. The Salae logic was extremely helpful and easy to use. It took me less than an hour to solve a problem I hadn't figure out in two days! Now I will be able to focus much more time in coming up with good radio libraries, instead of debugging silly problems.Share