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

[Martijn]

An easy test would be to set the PACKETPTR to a non RAM address after the START task. If the PACKTERPTR would have any effect it should cause a hardfault. But you should see no error and the RADIO just works prefectly.

[Susheel Nuguru]

Hi Martijn,

This is what is written in PS If the PACKETPTR is not pointing to the Data RAM region, an EasyDMA transfer may result in a HardFault or RAM corruption.

So it may or may not result in hardfault and the test is not very reliable way to test what you are saying. Also when the engineers have specially written specially that we should wait for DISABLED event, then I am sure they must have some concerns or possible race conditions that could happen if we do not do so. It is possible that the way you update PACKETPTR works for you in your use case possibly because of the size of smaller payload? or maybe because of other factors. But the question what do you gain by updating the PACKETPTR earlier than what I am recommending? Does it result in better throughput?

[Martijn]

You can transfer multiple packages with minimum delay between them, you don't have to disable the RADIO before starting another transfer. disabling the radio between each transfer, when you have multiple messages to send, is not very efficient.

I actually did not find anything in the PS that sais have to wait for the DISABLED event before updating the PACKETPTR. It only sais EASYDMA is finished when the DISABLED event occures. It does not say the PACKETPTR can only be set after a DISABLED event. It sais the PACKERPTR needs to be set before triggering the START task.

It would be very weird to use the END-START short when we can't even update the PACKETPTR in between. Then we can only send the same package again, or overwrite a previous received message, using that short.

If we both interpret the PS in different ways then I would like you to ask the engineer who designed it.

[Susheel Nuguru]

You have a point Martijn, I will now contact the engineer directly.