Received data is not stored in memory

[wszellen]

I have an issue where after transmitting a radio package, is setting up the radio as receiver, get indication for reception (have indications for ADRESS and PAYLOAD events, get the END event intterupt, but the data in payload is not the same as the radio packet (have the transmitter to write the payload on the SPI bus) but I get a correct (if I have calculated it correctly) value in the RXCRC register.

I have verified that I set the PACKETPTR register before I set the RXEN task (output the STATE register and it is 0) and that the PACKETPTR has the same value when the END event occure.

What can be the error that cause this to happen?

[ovrebekk]

Hi

Have you considered using the nrf_esb library in the SDK? Then you get all the packet handling, ACK and retransmit functionality for free.

Are you able to share your code for configuring and using the radio?

At the top of my head I can't think of any reason why the data pointed to by PACKETPTR wouldn't be updated when you get a valid END event in RX mode.

[butch]

Just thinking out loud... is the received data changed (not all zeros) but not equal to what was transmitted? Did you configure S0, LENGTH, S1 the same on the transmitter and receiver? (They will be read from and written to the buffer even if you are not considering them part of the 'payload.') On the nrf51 and nrf52 Reference Manuals both say 'The DISABLED event indicates that the EasyDMA has finished accessing the RAM', that is, maybe you should use a different event (DISABLED rather than END) . Again, I don't really know, I am just throwing out ideas.

[wszellen]

I found in an other thread that the EasyDMA is not completed until the DISABLED event was sent, but I have verified that the DISABLED event is completed (I check the STATE and it is 0) The S0, LENGTH and S1 lengths is all 0, since they are not used at all. If I clear the memory of the package, then it will still be 0 after the package is received, and that does not match the transmitted package. I am looking of what part of the code I can expose without exposing any confidential parts for the software.

[butch]

More ideas: You write PACKETPTR before each xmit or rcv? (you can't just set it once per session of the app, as documented in Nordic, and from my own experience.) Whitening enabled same on both rcvr and emitter? Buffer is not on the stack or heap where it could go out of scope and be reused? Buffer is C volatile so optimizations do not think it is never written and thus a constant in flash memory? (Try less optimization)

[wszellen]

Thanks for the idea Butch, PACKETPTR is written before each transmit and receive, have one global buffer for transmission of data and one global buffer for reception of data.

I can not see how the compiler can optimize throwing away a global buffer.