nRF52 receiving data from 24L01 incorrectly

RE: nRF52 receiving data from 24L01 incorrectly

cama — Tue, 28 Aug 2018 09:10:57 GMT

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.

RE: nRF52 receiving data from 24L01 incorrectly

cama — Mon, 27 Aug 2018 10:51:16 GMT

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.

RE: nRF52 receiving data from 24L01 incorrectly

Håkon Alseth — Sun, 26 Aug 2018 20:53:29 GMT

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

RE: nRF52 receiving data from 24L01 incorrectly

cama — Sat, 25 Aug 2018 20:52:29 GMT

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).

RE: nRF52 receiving data from 24L01 incorrectly

cama — Sat, 25 Aug 2018 15:29:53 GMT

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".

RE: nRF52 receiving data from 24L01 incorrectly

cama — Sat, 25 Aug 2018 11:10:56 GMT

I test same config as you. Only address and channel is my own.

Good news ... I send 0x123456 from nRF24 ... and i receive 0x2468AC to nRF52 !!! Like you. So it is just a SDK register settings problem (or nRF24 incompatible config). Time to lunch. I will make some modifications afternoon.

RE: nRF52 receiving data from 24L01 incorrectly

cama — Sat, 25 Aug 2018 08:36:41 GMT

Your are true. I am false. ESB does not need Softdevice. It is not Softdevice registers, but CPU registers.

Nordic proprietary protocols
 Example applications that show how to use Gazell and Enhanced ShockBurst (ESB) proprietary protocols.
 These examples do not require a SoftDevice.

And it is a good new for me. Because i am in pain with ESB too. And I try to solve an other problem. It means that my problem comes from me, or SDK. Not Softdevice. So i can solve by myself !

But my remark about packet sizing was correct. With ESB regular packet, you have one bit more than byte sized. While ShockBurst is byte sized. I think the only setting for selecting ESB on nRF24L01 is EN_AA. You disable it on your example. And nrf_esb SDK manage only ESB protocol. Not Shockburst.

Registers used by ESB SDK are :

NRF_RADIO->MODECNF0
NRF_RADIO->PCNF0
NRF_RADIO->PCNF1
NRF_RADIO->BASE0
NRF_RADIO->BASE1
NRF_RADIO->PREFIX0
NRF_RADIO->PREFIX1
NRF_RADIO->TXPOWER
NRF_RADIO->MODE
NRF_RADIO->CRCINIT
NRF_RADIO->CRCPOLY
NRF_RADIO->CRCCNF
NRF_ESB_SYS_TIMER->PRESCALER
NRF_ESB_SYS_TIMER->BITMODE
NRF_ESB_SYS_TIMER->SHORTS
NRF_ESB_SYS_TIMER->TASKS_CLEAR
NRF_ESB_SYS_TIMER->CC[]
NRF_ESB_SYS_TIMER->EVENTS_COMPARE[]
NRF_ESB_SYS_TIMER->TASKS_STOP
NRF_PPI->CH[].EEP
NRF_PPI->CH[].TEP
NRF_PPI->CHENSET
NRF_RADIO->SHORTS
NRF_RADIO->INTENSET
NRF_RADIO->TXADDRESS
NRF_RADIO->RXADDRESSES
NRF_RADIO->FREQUENCY
NRF_RADIO->PACKETPTR
NRF_RADIO->EVENTS_ADDRESS
NRF_RADIO->EVENTS_PAYLOAD
NRF_RADIO->EVENTS_DISABLED
NRF_RADIO->TASKS_TXEN
NRF_RADIO->TASKS_RXEN
NRF_RADIO->PACKETPTR
.. etc ...

... a lot ... Take a look at nRF5_SDK_15.0.0\components\proprietary_rf\esb\nrf_esb.c file. It may helps you.

I suspect your config, as API config, generate a misconfig (or incompatible with you nRF24L01 setup) config by registers (SDK job). But what register ? I don't know. And i don't know if you can setup a ShockBurst mode by registers (without SDK).

I will try your setup. Please tell me your TX_ADDRESS, TX_ADR_WIDTH. And I notice you did not setup payload size on nRF24L01 side (PW_P0).

RE: nRF52 receiving data from 24L01 incorrectly

Lam — Sat, 25 Aug 2018 02:36:04 GMT

void TX_Mode(void)
{														 
    

  	SPI1_Write_Buf(SPI_WRITE_REG+TX_ADDR,(uint8_t*)TX_ADDRESS,TX_ADR_WIDTH);    
	  
  	SPI1_Write_REG(SPI_WRITE_REG+EN_AA,0x00);    

  	SPI1_Write_REG(SPI_WRITE_REG+EN_RXADDR,0x00); //0x01  //close--0x00

  	SPI1_Write_REG(SPI_WRITE_REG+SETUP_RETR,0x00);//0x1a  //close--0x00

  	SPI1_Write_REG(SPI_WRITE_REG+RF_CH,0x49);     //频率，0x00~0x4e    

  	SPI1_Write_REG(SPI_WRITE_REG+RF_SETUP,0x08);  //0x26  ---- 250k    //0x0f ----2M   //0x06 ----1M   //B1000-0x08  -18db    //B1110-0x0f  0db 

  	SPI1_Write_REG(SPI_WRITE_REG+CONFIG,0x0a);    //0x0e--16crc    //0x0a--8crc
        
	CE_H;                                  
}

24L01+ using Shorkburst but not ESB? How do I know what protocol it is using? As far as I know, it uses ESB as default?

Thanks

RE: nRF52 receiving data from 24L01 incorrectly

Lam — Sat, 25 Aug 2018 02:14:17 GMT

nRF52 using SoftDevice to transmit ESB packet? In the test, I didn't download the SoftDevice to the module.

If I should modify the registers, what registers should I need to do with? I look for it at the production specification of nRF52832, but it seems that it has no related registers about ESB, but it does have some about radio.

Maybe I should modify these radio register, right? I am a little confused.

Thanks.

RE: nRF52 receiving data from 24L01 incorrectly

cama — Fri, 24 Aug 2018 08:45:05 GMT

ESB packet format is byte sized. Except data control, just before the payload : It uses 9 bits. One bit more than a byte. Coincidentally you are one bit shifted.

Problem : It is Softdevice who build the ESB packet. Not the SDK lib. The SDK lib just send 2 complete bytes (payload size as one byte, and packet id + noAck as separed byte, then not 9 bits compliant suggesting a conversion by Softdevice) and payload to Softdevice. With no source code, you can not check or modify Softdevice behavior. The only interact is registers modifications.

Not a solution, but may helps you.

RE: nRF52 receiving data from 24L01 incorrectly

Håkon Alseth — Fri, 24 Aug 2018 08:34:36 GMT

Are you sending ESB-packets from the nRF24L01+, or are you using the older "shockburst" packet format?

Could you post the nRF24L01+ configuration that you are using? A register dump would suffice.

Cheers,

Håkon

RE: nRF52 receiving data from 24L01 incorrectly

Lam — Fri, 24 Aug 2018 01:09:05 GMT

I have several 24L01+ modules and they can work well with each other. Also I have several nRF52832 modules and they work well too.

Since 24L01+ can receive data correctly from 24L01+, the 24L01+ may not have problem and so does nRF52832. It is so strange.

RE: nRF52 receiving data from 24L01 incorrectly

Håkon Alseth — Thu, 23 Aug 2018 13:50:37 GMT

That is strange. Looking at the bit stream, it seems that your data is shifted one bit (0x676767 << 1 becomes 0xCECECF).

Do you have several nRF24L01+ modules, and they all behave like this? Do you have a link to where you obtained them?

Kind regards,

Håkon

RE: nRF52 receiving data from 24L01 incorrectly

Lam — Thu, 23 Aug 2018 13:20:03 GMT

Thanks for your suggestion.

The program running on the nRF52832 was modified from the nRF52 SDK 15.0.0 esb_prx example. It uses the nrf_esb library to recieve data.

A part of my code which config the esb is as follows.

uint32_t esb_init( void )
{
    uint32_t err_code;
    uint8_t base_addr_0[3] = {0xE7, 0xE7, 0xE7};
    uint8_t base_addr_1[3] = {0xC2, 0xC2, 0xC2};
    uint8_t addr_prefix[2] = {0xE7, 0xC2};
    nrf_esb_config_t nrf_esb_config         = NRF_ESB_LEGACY_CONFIG;
    nrf_esb_config.payload_length           = 3;
    nrf_esb_config.crc 	                	= NRF_ESB_CRC_8BIT;
    nrf_esb_config.protocol                 = NRF_ESB_PROTOCOL_ESB;
    nrf_esb_config.bitrate                  = NRF_ESB_BITRATE_2MBPS;
    nrf_esb_config.mode                     = NRF_ESB_MODE_PRX;
    nrf_esb_config.event_handler            = nrf_esb_event_handler;
    nrf_esb_config.selective_auto_ack       = false;

    err_code = nrf_esb_init(&nrf_esb_config);
    VERIFY_SUCCESS(err_code);		
		
    err_code = nrf_esb_set_rf_channel(73);
    VERIFY_SUCCESS(err_code);
		
    err_code = nrf_esb_set_address_length(4);
    VERIFY_SUCCESS(err_code);

    err_code = nrf_esb_set_base_address_0(base_addr_0);
    VERIFY_SUCCESS(err_code);

    err_code = nrf_esb_set_base_address_1(base_addr_1);
    VERIFY_SUCCESS(err_code);

    err_code = nrf_esb_set_prefixes(addr_prefix, 2);
    VERIFY_SUCCESS(err_code);

    return err_code;
}

I don't know where I should modify my code.

Thanks

RE: nRF52 receiving data from 24L01 incorrectly

Håkon Alseth — Thu, 23 Aug 2018 10:55:49 GMT

Hi,

It sounds like you have configured the radio incorrectly, especially the endianess of the nrf52 radio (see PCNF1 register)

Have you tried using nrf_esb library for nRF52 to see if that works better?

Kind regards,

Håkon