NORDIC NRF24L01 COMMS problems

[Tangent_Tracker]

Hi folks, I am trying to talk to the above RF module from a PIC 16F688. It is my first time with SPI, and to complicate matters I code in assembly LOL...

Anyway, I am happy with my SPI routine, I think, but I am not quite understanding the Nordic manual...

I will get down and tell you what I am transmitting, receiving, and maybe someone would be good enough to give me a pointer as to where I am going wrong, if at all!

Timings are deliberately slow as I am on a breadboard...

Clocking at 500uS per 1 cycle
CSN to the first clock is 280uS
space between end and start clocks approx 1mS
last clock to CSN high is 100uS

So, to initialize...

I am sending 0x33 to 0x00 (config) and this is what I am seeing out...

MOSI 0x00 (conf addy)
MISO 0x0E

MOSI 0x33
MISO 0x08

Which doesn't seem to make any sense to me!

I hope this is just a case of 'can't see the wood for the trees'.

Please Help!!!

[stmdude]

Sorry, it's been about a million years since I used the NRF24L01+ chips, so I don't remember the particulars.

However, this was my main source of information, which might help:
https://github.com/nRF24/RF24

[Tangent_Tracker]

Thanks, not sure where to start with that resource. I struggle to read 'C' or derivatives! I would just love to see some timing diagrams or scope shots and I'll be happy, but there just seems to be absolutely nothing! I know my code is sort of working, in that I am getting a response, just struggling to see any pattern or controllability that is all!
Frustrating!

[alexig]

Hi,

Hopefully you might have sorted it out by now but if not, you can't just write 0x00 to access the config, you need to also add in the bit for "W_REGISTER" (0x20) to it. For reading, it's the same thing, add in the "R_REGISTER". See page 51 for SPI commands.

[Tangent_Tracker]

Thanks Alex, yes, it was a "I can't see wood for trees moment" to be fair! I still can't recieve data. I have seen a spike in test mode on a spectrum analyser at work, and I have tested FIFO status after filling pipe0 with 3 bytes, then tested again after holding CE high for 10ms, first time round I get 0x01, after CE it becomes 0x11. So clearly it is flushing the Tx buffer. Just the recieving unit shows no response, neither in interupt nor when I test FIFO status after.

I am trying to keep everything simple, following the procedures outlined for communicating with the older non + on page 74, and in the same order (I am commanding many modules at once so cannot use ACK etc.) so all bits in EN_AA ere set to 0, retrans all 0, no CRC and all data in and out of a 3-byte address assigned to pipe 0. I am a little puzzled because everything looks good atm! Only thing I am not doing is delivering the data to the W_TX_PAYLOAD_NO_ACK register address, but I assumed that was for shockburst only 

[TK]

Are you using the correct SPI transfer mode that NRF24L01 expects?

Clock polarity (CPOL) and clock phase (CPHA)

[Tangent_Tracker]

Hi Alex yes as far as I can see, as you can see from the screenshot above, exactly as per the manual, that is, CPOL 0, CPHA 0.

[alexig]

I have tested FIFO status after filling pipe0 with 3 bytes, then tested again after holding CE high for 10ms, first time round I get 0x01, after CE it becomes 0x11. So clearly it is flushing the Tx buffer. Just the recieving unit shows no response, neither in interupt nor when I test FIFO status after.

That's promising but also a bit strange as I would think the TX_FULL would change after the first packet is sent. Try to clear  TX_DS and see if it is re set. On the TX you just need to pulse the CE pin for a minimum of 10us to send a packet. On the RX you should leave CE high so it will always be listening, you could turn CE low once a packet is received if you wanted to.

I am trying to keep everything simple, following the procedures outlined for communicating with the older non + on page 74

I would probably go one step simpler than that, just have a nRF24L01 on the TX and RX with enhanced shockburst on by default that way you know you can receive and send a packet then slowly start changing bits of it at a time, turn off auto ack, auto reply,

Looks like W_TX_PAYLOAD_NOACK can be used for a single packet transmit on the TX so the RX won't send a reply back, but yes you won't need this.

[Tangent_Tracker]

Thanks Alex. On your first point, surely if TX_FIFO was never full in the first place, then I would not have thought to see any change? Remember, I am only sending 3 bytes of data.

I like your second idea Alex, I am beginning to think that there is something wrong with trying to use these particular modules without shockburst. They will be almost certainly Chinese rip-offs and I am willing to bet no one else has really bothered using them with no ack or CRC etc, especially with all the pre-built scripts out there already. I might be attempting something that in this case, is just not going to happen!

Will try shockburst later on.

[alexig]

Oh right, I misread it, I thought you were loading up 3 packets instead of 3 bytes. What if you read the status before writing the 3 bytes? What if you just load 1 byte?

If it's those modules with the black blob instead of the nRF24 chip, those are marked as "compatible" but who knows if they really work!

[Tangent_Tracker]

Alex it was me all along. Sorted now mate, I had not entered a Tx address like a fool. There were other little bugs to iron out too. I guess it is easier to miss something in assembly, I must migrate to C!!!

Hey, these were really cheap, current consumption is around 20mA in transmit, although need to use a scope to test this properly, and Range is excellent! Very impressed!


Anyway thanks for your help!