Received data is not stored in memory

RE: Received data is not stored in memory

butch — Tue, 04 Oct 2016 14:17:25 GMT

Almost out of ideas. It sounds like you are writing a proprietary protocol. Compare your code to Nordic examples such as ESB, the RadioHead NRF51 implementation, and to my open source nrfRawProtocol on Github.

RE: Received data is not stored in memory

wszellen — Tue, 04 Oct 2016 14:09:32 GMT

Thanks for looking into this Butch, but I have set the PACKETPTR to the address of my buffer, then I have written the value of PACKETPTR as debug output and it is located in RAM, then I have writted the value that PACKETPTR is pointing at as debug output and no data is located there.

RE: Received data is not stored in memory

butch — Tue, 04 Oct 2016 14:06:46 GMT

I admit it is highly unlikely. The compiler can see that you never wrote to the receive buffer. It doesn't know that the radio device does. The compiler can think it is a constant, and put it in flash. But the Nordic docs say it MUST be in RAM and if not you MIGHT get a hard fault (I could be misquoting, see the original.) If it were in FLASH, the radio's write would have no effect and if it did not generate a hard fault...

RE: Received data is not stored in memory

wszellen — Tue, 04 Oct 2016 13:19:25 GMT

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.

RE: Received data is not stored in memory

butch — Tue, 04 Oct 2016 13:13:17 GMT

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)

RE: Received data is not stored in memory

wszellen — Tue, 04 Oct 2016 08:53:10 GMT

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.

RE: Received data is not stored in memory

butch — Mon, 03 Oct 2016 14:35:08 GMT

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.

RE: Received data is not stored in memory

ovrebekk — Mon, 03 Oct 2016 14:20:10 GMT

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.