When can the PACKETPTR register be updated?

[abkirchhoff]

I am using the radio in the nRF52832 to support a custom protocol. I would like to send two packets in a row, each with different payloads, on the same frequency. When can I safely update the PACKETPTR register to point to the new packet contents? After the PAYLOAD event or after the END event?

After the PAYLOAD event would be ideal, as this would allow me to use the END->START shortcut, provided I can update the PACKETPTR register in the time it takes to transmit the CRC. The datasheet actually says to wait until after the DISABLED event, but I am hoping that is not the case.

Thanks!

[Martijn]

It even sais this in the nrf52 PS:"As illustrated in Figure 1, the RADIO's EasyDMA utilizes the same PACKETPTR for receiving and transmitting packets. The CPU should reconfigure this pointer every time before the RADIO is started via the START task."

I read this as PACKETPTR is read and taken over when start task is triggered. changing the PACKETPTR after the START task has been triggered has no effect. So: set PACKETPTR -> trigger START -> wait for for ADDRESS event -> set PACKETPTR -> do START again via SHORT after END event. This is a perfectly safe sequence. This is the case for TX and RX.

This is also exactly the behaviour we see in the nrf51. I don't see why this would be any different from the nrf52. I would be very surprised if this was changed in the nrf52.

It is true the DISABLED event indicates EASYDMA is finished, but when the EASYDMA is busy it has no connection to the PACKETPTR anymore (it is read once during START task).

[jane_song]

Hi Martjin,

  Absolutely!

   I saw your point recently and I also agreed with your  sequence: set PACKETPTR -> trigger START -> wait for for ADDRESS event -> set PACKETPTR -> do START again via SHORT after END event.It is efficient to disable the radio between each transferring and  receiving.When using the shortcut of end_start for fast continuous receiving and consider the delay of kernel entering isr handler,it seems safe to reconfigure the PACKETPTR on address event for next packet.