Interesting NRF24L01/MIRF V2 problem (with hacky solution)

Wireless & IoT
1

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 ass) 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?](http://projects.horizons-edge.com.au/DSCF3712.JPG)](http://projects.horizons-edge.com.au/HE0034B_assembled_twins.jpg)

2

By toggling /CS, you’re effectively restarting the transaction roughly 1 SCK

into the sequence (note the skewing of MISO between the two traces).

I suspect this is actually masking a problem with your SCK settings. I use

CPHA=0, CPOL=0 (Motorola definitions; some manufacturers – read “TI” –

invert the definition of CPHA). Worst case, there are only 4 possible

settings of CPHA + CPOL, so you can just try them all.

(Testing the SPI between two identical hosts won’t show up this kind of

problem – a bit like talking over a UART where both ends are set to

12345bps or something. The setting(s) may be “wrong”, but they agree.)