ADDRESS affects radio rampup time?

[SebastianA]

We had a strange problem with a test case of ours. We use the radio in 1Mbps BLE mode and send two packets, then receive one packet.

Our test case normally works, but fails when we use address 0x4F7D2A92 for our packets.

We need to send the packet at a specific time and we don't want to have the radio turned on too early in order to save energy. So we trigger TXEN and START via PPIs from TIMER0's COMPARE 0 & 1. With the address above, the time between our events were too short so the READY even came just after we sent START. It also seems like the RX rampup can be shorter or longer depending on the address being used.

Are these correct observations?

[SebastianA]

I was measuring the time for the START/READY event to happen via IO pins and an oscilloscope. When I instead store the time of the READY signal via TIMER0's CAPTURE[2] and compare it to COMPARE[0], it always seem to be 40us later. Is there a sub-us clock that could affect this?

If all I change in our test is the address, it works/doesn't work depending on the address. If I change the time allowed for rampup from 40 to 42us it works fine with the above address as well.

Our code once reads access_address from UICR, then does this every time before using the radio:
    nrf_radio_base0_set((access_address & 0x00ffffff) << 8);
    nrf_radio_prefix0_set((access_address & 0xff000000) >> 24);


That's the only thing in our code that depends on the address.

When it doesn't work, from what I can see is that we don't get a DISABLED event. We use a PPI to send DISABLE when a timeout happens and we have a short and PPI group to disable that timeout when ADDRESS events happens. We also have the END->DISABLE short enabled.

When we don't receive a packet, the timeout happens for this address and we get the DISABLED event.

With the address mentioned above we don't get it. I've checked that we get the ADDRESS event by letting it also toggle a pin.

We've configured the radio with a maxlen of 255 for the packet and we've reserved 20ms for the time slot. Even if the length field in the packet would become incorrectly received, we should still have enough time to receive the whole, invalid packet and get a DISABLED event.

Could the ADDRESS value affect anything else here?

[Sigurd]

Hi!

What SDK version are you using?

If you are only seeing this on nRF52832, then maybe you are seeing some of the nRF52832 radio erratas in play.

https://infocenter.nordicsemi.com/topic/errata_nRF52832_Rev1/ERR/nRF52832/Rev1/latest/anomaly_832_102.html

https://infocenter.nordicsemi.com/topic/errata_nRF52832_Rev1/ERR/nRF52832/Rev1/latest/anomaly_832_106.html

https://infocenter.nordicsemi.com/topic/errata_nRF52832_Rev1/ERR/nRF52832/Rev1/latest/anomaly_832_107.html

They are fixed in the latest revision of the nRF52832, but you need to make sure this workaround here is applied:

https://infocenter.nordicsemi.com/topic/errata_nRF52832_Rev3/ERR/nRF52832/Rev3/latest/anomaly_832_182.html

[SebastianA]

We use nRF5-SDK 17.1.0. The boards uses nRF52832 rev-2 and rev-1. I'm not in the office today so I can't say weather it was with rev 1 or 2 we got this error with the given address.

We have a few checks when selecting the address, so it can never be affected by #107. #106 shouldn't really matter here, a high packet loss is handled by our test (we run it until we've got 3000 working transactions). I think our address checks will also avoid triggering it.

#102 seems similar, the strange thing is though that it fails almost every time with the mentioned address, but not with most other addresses. Is the <0.1% failure rate related to the content of the packet or is it completely random? I'll test again with that workaround when I get back to the office.

[SebastianA]

It was with rev-1 and the workaround for anomaly 102 fixes it.

We would rather not lower the sensitivity with 3 dB though. Is it depending on the address when it happens so we could avoid those addresses?

[Sigurd]

Hi!

SebastianA said:

It was with rev-1 and the workaround for anomaly 102 fixes it.

Great!

This is fixed on later revisions, so for Rev2 and Rev3, you don't need to apply the workaround for errata 102. 

Rev2 replaced Rev1 in 2018. So I guess you are not actually creating any products with Rev1. If you have Rev1 in your test-setup/CI, I suggested replacing them with Rev2/Rev3.

[SebastianA]

Our software is used for mesh networking by 3rd parties and they do update deployed products. Some of them use rev 1 chips. A loss of sensitivity could make their networks perform below requirements so I'd rather avoid it if it possible. If it just happens when certain addresses are used, we would rather try to avoid those addresses when generating new addresses.

[Sigurd]

SebastianA said:

If it just happens when certain addresses are used, we would rather try to avoid those addresses when generating new addresses.

Certain addresses might trigger it more easily, but as far as I know, it can happen with any address. You could check the revisions of the chip in FW, and only apply the workaround for the affected chips. ref. apply_address_workarounds() in nrf_esb.c

[SebastianA]

Yes, we'll have to solve it like that. Thanks!