ADDRESS affects radio rampup time?

RE: ADDRESS affects radio rampup time?

SebastianA — Thu, 25 Apr 2024 10:54:28 GMT

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

RE: ADDRESS affects radio rampup time?

Sigurd — Thu, 18 Apr 2024 11:36:07 GMT

[quote user="SebastianA"]If it just happens when certain addresses are used, we would rather try to avoid those addresses when generating new addresses.[/quote]

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

RE: ADDRESS affects radio rampup time?

SebastianA — Fri, 05 Apr 2024 13:57:05 GMT

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.

RE: ADDRESS affects radio rampup time?

Sigurd — Fri, 05 Apr 2024 12:11:16 GMT

Hi!

[quote user="SebastianA"]It was with rev-1 and the workaround for anomaly 102 fixes it.[/quote]

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.

RE: ADDRESS affects radio rampup time?

SebastianA — Fri, 05 Apr 2024 11:03:45 GMT

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?

RE: ADDRESS affects radio rampup time?

SebastianA — Thu, 04 Apr 2024 11:12:58 GMT

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.

RE: ADDRESS affects radio rampup time?

Sigurd — Thu, 04 Apr 2024 08:38:01 GMT

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

RE: ADDRESS affects radio rampup time?

SebastianA — Tue, 02 Apr 2024 14:08:00 GMT

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?

RE: ADDRESS affects radio rampup time?

Amanda Hsieh — Wed, 27 Mar 2024 18:25:36 GMT

Hi,

Due to the Easter holidays in Norway, we are less staffed than usual. You can expect an answer sometime next week,

Sorry for the inconvenience and thanks for your patience.

Regards,
Amanda