nRF52 receiving data from 24L01 incorrectly

[Lam]

Hi,

I am using a 24L01+(as PTX) communicating with a nrf52832(as PRX).

I can have these two device communicating, where nrf52832 can receive data from 24L01+.

However, the data nrf52832 received is not the exactly same as the data 24L01+ has transmitted. For example, the 24L01+ is transmitting a 3-byte data(e.g. 0x123456) to nRF52832, while the data nRF52832 received is 0x2468AC. As you can see, 0x2468AC = 0x123456 <- 1. However, in another test, the 24L01+ transmitted 0x676767, while the nRF52832 received 0xCECECF.

Any suggestion would be appreciated. 

Best regards!

[cama]

I receive 0x2468AD, but it is inconstant. I receive only one packet, for three or four sending (low power, and no packet reprtition).
The radio event register for RX receiving is NRF_RADIO->EVENTS_DISABLED, and NRF_RADIO->INTENSET & RADIO_INTENSET_DISABLED_Msk (I know, the name did not help to found ...). Current received datas are on NRF_RADIO->PACKETPTR register.
The auto-ack behavior is coded on SDK. Then, sometimes CPU call a function who read payload for ack checking, other times CPU call function that store payload on a custom specific FIFO (defined inside the same API).
You can found the code that manage new received packet at "on_radio_disabled_rx" function. And 'rx_fifo_push_rfbuf(NRF_RADIO->RXMATCH, p_pipe_info->pid);' decode new received buffer.
I can see some problems :
- As configured, nRF52 manage ACK. But your nRF24 setup don't care about ACK. It is not your problem for now, but it can be if you don't manage ACK by your own on nRF24 side.
Strangely, the SDK test is : 

if ((m_config_local.selective_auto_ack == false) || ((m_rx_payload_buffer[1] & 0x01) == 1))
ack = true;

That says if no_ack packet flag is true, then manage ACK. Strange ... I notice some no_ack bit inversions pretty much everywhere on ESB SDK. And it is difficult to understand when all are named 'no_ack'. Maybe it works with nRF52 ... luckily.
But don't comply with nRF24L01 datasheet : "Setting the flag high tells the receiver that the packet is not to be auto acknowledged.". Unless if nRF52 CPU invert it internaly ...
- What happens if I use CRC16 ? Same result. I receive 0x2468AD, but very few.
- If I enable ESB on nRF24, or dynamic payload (because enabling dynamic payload RF24_DYNPD enable automaticaly ESB), I receive nothig.
- If I send 0xF23456, I receive 0xE468AD. No CRC error. Payload is 1 shifted and 1 added.
- Function rx_fifo_push_rfbuf decode payload buffer as :
1 byte : payload size
1 byte : packet id + packet no_ack flag
n bytes : payload
Problem : You setup nRF24 as ShockBurst, not ESB. So normaly, sent packet miss 9 bits of data control, just before the payload.
How on earth the nRF52 CPU receive the right payload with only 1 bit shifted, while it miss 9 bits ???
How on earth the nRF52 CPU check CRC8 and accept the packet with improper data, improper format and improper packet size ?
I think that data control still present. Despite configuration.
"CRC is calculated over the address, PacketControl Field and Payload" (datasheet).
Conclusion :
On-air packet is conform to nRF52 setup, because CRC check is ok. But, strangely, NRF_RADIO->PACKETPTR contains a shifted payload, while payload was correct at CRC check.
If anybody know how nRF52 manage payload on this process, it can help to find registers configuration problem. Page 205 of nRF52832 datasheet, this process is called "packet disassembler".

[cama]

Some news ...
My problem is the opposite. I want to use nrf52 as TX and nrf24 as RX. Of course, it does not work. I found no complete setup or example on the web. Only incomplete, bugged files, only nrf24 side or only nrf52 side.
But after looking to my and your problems, and spending hours on datasheet and nrf_esb, I am conviced that I can make ESB by my own without NRF SDK. I will save time, after loosing a lot !
Not the first time ... I spend days to try to use v13 nrf_log, app_uart, nrf_drv_uart, nrf_serial, ... now I know they are rubish ! For each lib, conclusion is the same : bad design, not API level, bugged, too complicated (risky), poor performances, too immature for some nrfx.
If we needs to learn datasheet and analyse SDK code for each lib, and it's interfaces changes quicker than the hardware, what are these libs ?
Among libs I try, only BLE libs works without major problems. Fortunately ! Maybe NRF SDK is good for complicated features only.

So I handle radio IRQ by my own now, and I can get raw data. With your setup, I get :

NRF_RADIO->CRCSTATUS=1
NRF_RADIO->RXMATCH=0
NRF_RADIO->RXCRC=0xFE
NRF_RADIO->PCNF0 = 0x00010100 = 0000 0000 0000 0001 0000 0001 0000 0000 : S0LEN=1, S1LEN=1
NRF_RADIO->PCNF1 = 0x01030606 = 0000 0001 0000 0011 0000 0110 0000 0110
NRF_RADIO->PACKETPTR=0xFF002468AC

S0LEN + S1LEN = 9bits, as configured by SDK. That is correct. If I increase S1LEN to compensate shifting, CRC is rejected. So, the problem comes after CRC check, on packet disassembly.

Conclusion : CRC is ok, but payload is not conform to CRC check and original message. As I say on last message, we need to know what appens on CPU "packet disassembler" process. Which register can interfer with this process (PCNF0, PCNF1, ...) ?
How this process extract the 9 bits of data control, to make two bytes on PACKETPTR ?

Additionally, with my own lib, I get complete and rigth packet for each nRF24 transmission. Unlike nrf_esb, that get only one RX for 3 or 4 TX (I don't know why, and I do not care now).

[Håkon Alseth]

Hi,

 

You're using ShockBurst, as you are disabling EN_AA and setting field ARC in register SETUP_RETR to '0'. This will effectively omit the 9 bit "PCF" field from the on-air RF payload, as explained in the nrf24l01+ datasheet in chapter 7.9. The nRF52 library nrf_esb expects to receive in ESB mode, not SB mode.

The nrf_esb library does not support the legacy "shockburst" mode, unfortunately.

 

Kind regards,

Håkon

[cama]

Hi. Thank you for reply.

Same confing as LamGELI. Now I enable EN_AA, and ARC is set to 5. As recommanded.

I allways get CRC mismatch (CRCSTATUS=0). While nRF24 in ShockBurst mode make right CRC for nRF52 side, but false payload (one bit shifted). I notice that every received radio event, have payload first byte to 0x00 (payload size). Then I enable dynamic payload too, at nRF24 side : Same result.

Otherwise, I try to make ShockBurst on nRF52 side with S0LEN=0 and S1LEN=0 : same result, CRC errors.

Maybe LamGELI will have more luck.

[cama]

LamGELI, if you're still interested, I found the right nRF52 config for your original nRF24 setup.

You must set registers as : LFLEN=0; S0LEN=0; S1LEN=0; BALEN=4; MAXLEN=payload_size; STATLEN=payload_size.

For this, you could modify update_rf_payload_format_esb function on nrf_esb.c SDK.

With this config, CRC check if good, and you receive right data on payload buffer.