When can the PACKETPTR register be updated?

RE: When can the PACKETPTR register be updated?

jane_song — Tue, 19 Mar 2019 03:05:10 GMT

Absolutely!

RE: When can the PACKETPTR register be updated?

jane_song — Tue, 19 Mar 2019 03:04:10 GMT

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.

RE: When can the PACKETPTR register be updated?

Martijn — Wed, 09 Mar 2016 13:59:56 GMT

great! thank you for confirming!

RE: When can the PACKETPTR register be updated?

abkirchhoff — Wed, 09 Mar 2016 13:14:26 GMT

Thanks Aryan for looking into this question.This information is very useful. Thanks Martijn for you participation as well.

I didn't mention it before, but I am sending packets to a nRF24L01+, which limits me to 32 byte payloads. I am hoping to send two consecutive packets to the nRF24L01+ as it has a 3 packet FIFO, and with this new information, it looks like the nRF52832 will be able to do so.

RE: When can the PACKETPTR register be updated?

Susheel Nuguru — Wed, 09 Mar 2016 12:53:17 GMT

Hi,

@abkirchhoff : It should be ok to use END for RX as well as TX, as long as we have a CRC > 0 byte. If the CRC is 0 byte I do not think we can guarantee that the last byte received at END is moved to RAM before the END event has reached to the CPU. I assume that the PS has written DISABLED to make it simple and safe keeping BLE in mind and forgot that RADIO does not need to be disabled for every transaction.

@Martijn: The PACKETPTR is latched (double buffered) on START task, i.e. the EasyDMA stores a copy of the register on START. So you were right, we can update it any number of times before TASK_START and value at the time of START task will be latched to be used by EasyDMA.

RE: When can the PACKETPTR register be updated?

Susheel Nuguru — Wed, 09 Mar 2016 11:23:14 GMT

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

RE: When can the PACKETPTR register be updated?

Martijn — Wed, 09 Mar 2016 09:18:31 GMT

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.

RE: When can the PACKETPTR register be updated?

Susheel Nuguru — Wed, 09 Mar 2016 08:46:45 GMT

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?

RE: When can the PACKETPTR register be updated?

Martijn — Wed, 09 Mar 2016 08:21:09 GMT

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.

RE: When can the PACKETPTR register be updated?

Martijn — Wed, 09 Mar 2016 08:15:45 GMT

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

RE: When can the PACKETPTR register be updated?

Susheel Nuguru — Wed, 09 Mar 2016 07:47:56 GMT

One update though, The CRC is calculated on the fly in the hardware while TX/RX, So for TX even though we are sure that getting PAYLOAD, ADDRESS or END event marks for sure that EasyDMA is finished but that does not mark the it is safe to update the PACKETPTR because can still be CRC pending.

I think we will stick to what PS says that we need to wait for the DISABLED event and not rely on theories. We would not achieve any significant throughput or power advantages on taking this risk.

RE: When can the PACKETPTR register be updated?

Susheel Nuguru — Wed, 09 Mar 2016 07:39:03 GMT

I am sorry, my last comment got deleted somehow. I will rewrite it

I agree with abkirchhoff, getting PAYLOAD, ADDRESS or END event should theoretically be enough in TX mode to know that the EasyDMA has done fetching the packet from RAM.

@Martijn: I can see that the decision point is little blurry when it comes to TX mode, but for RX you have to wait until you get the DISABLED event.

RE: When can the PACKETPTR register be updated?

Martijn — Wed, 09 Mar 2016 07:19:10 GMT

In de nrf51 the START task was used as a decision point for the PACKETPTR. Isn't this the same in the nrf52?

If so, the address event should be the first indication it is safe to update the PACKETPTR (the start task is passed). We use this in our nrf51 applications.

I was looking at it right now and noticed there are no mentions of decision points at all in the nrf52 documentation. I guess this should be updated

RE: When can the PACKETPTR register be updated?

abkirchhoff — Tue, 08 Mar 2016 17:36:46 GMT

That makes sense for the receive operation. For a transmit operation, a PAYLOAD event indicates that the payload has been sent over the air. Thus, the packet must have been read from RAM by the time that event occurs. The EasyDMA would be done accessing RAM and the PACKETPTR could be changed. Would you agree with my theory? Am I missing anything?

RE: When can the PACKETPTR register be updated?

Susheel Nuguru — Tue, 08 Mar 2016 17:02:11 GMT

In this I mentioned that it is safest to update PACKETPTR when you get the disabled event. That is when we are sure that EasyDMA is has finished accessing RAM.