- Fri Apr 25, 2008 12:05 am
#47012
I spent the last week or so pulling my hair out over communications problems with a uMiRF V2 board - Figured it's probably because I havent really worked with SPI yet, and therefore it's likely a problem with my firmware.
So I built two of these, which are basically pic24FJ48GA002 micros with an EEProm, support hardware and a bilateral switch (for hard I2C reset) made to slot nearly into a breadboard, since SPI debugging without jumper wires can be an absolute pain. I wired them together as shown here, and wrote some quick firmware to dump on them both. RB13 pulled HIGH makes one master (green LED), LOW makes one slave (RED LED)
To my surprise the hardware SPI routines written previously worked perfectly. Ie: it wasn't an issue with SPI, as I was able to transmit questionable phrases from one board to the other via SPI and print them via UART2 without issues. So I checked the all the data lines on my scope. Everything seems fine, timing is exactly as shown in the 24L01 datasheet yet I'm still receiving invalid data from the 24L01 (ie: registers listed as having a default value of 0xE7 are giving random results)
After alot of head (and ***) scratching, I recompiled and flashed one of the micros to give it one more shot. IT WORKED! WTF!?!
Every register I queried gave the correct default value - upon checking my code to see what I may have changed, I noticed I accidentally toggled the SSN line halfway through issuing the command 0x0E - this is what it looks like on the scope: http://www.podecoet.org/24l01_working.jpg - the red arrow indicates the accidental toggle
Having no idea why that worked, I decided to remove the toggle, and reflash to try again - scope capture after removing the anomaly: http://www.podecoet.org/24l01_notWorking.jpg --- The problem returned! I then proceeded to try and toggle SSN at different times - First before transmitting the MSB, then after transmitting the LSB. Surprisingly, both failed with the same result! So what the hell is going on?
In the 24L01 manual, 8.3.1, page 45, It says:
So I built two of these, which are basically pic24FJ48GA002 micros with an EEProm, support hardware and a bilateral switch (for hard I2C reset) made to slot nearly into a breadboard, since SPI debugging without jumper wires can be an absolute pain. I wired them together as shown here, and wrote some quick firmware to dump on them both. RB13 pulled HIGH makes one master (green LED), LOW makes one slave (RED LED)
To my surprise the hardware SPI routines written previously worked perfectly. Ie: it wasn't an issue with SPI, as I was able to transmit questionable phrases from one board to the other via SPI and print them via UART2 without issues. So I checked the all the data lines on my scope. Everything seems fine, timing is exactly as shown in the 24L01 datasheet yet I'm still receiving invalid data from the 24L01 (ie: registers listed as having a default value of 0xE7 are giving random results)
After alot of head (and ***) scratching, I recompiled and flashed one of the micros to give it one more shot. IT WORKED! WTF!?!
Every register I queried gave the correct default value - upon checking my code to see what I may have changed, I noticed I accidentally toggled the SSN line halfway through issuing the command 0x0E - this is what it looks like on the scope: http://www.podecoet.org/24l01_working.jpg - the red arrow indicates the accidental toggle
Having no idea why that worked, I decided to remove the toggle, and reflash to try again - scope capture after removing the anomaly: http://www.podecoet.org/24l01_notWorking.jpg --- The problem returned! I then proceeded to try and toggle SSN at different times - First before transmitting the MSB, then after transmitting the LSB. Surprisingly, both failed with the same result! So what the hell is going on?
In the 24L01 manual, 8.3.1, page 45, It says:
The SPI commands are shown in Table 16.. Every new command must be started by a high to low transition on CSN.I'm starting to question whether or not they meant a HIGH-LOW transition AFTER issuing the command, but the timing diagram (Figure 23, Page 47) doesn't reflect this... Anyone ever seen anything like this before?