Why does nrf_rtc_timer default to a 15-bit counter on the nRF52832?

[Alex]

Hello!

We have a nRF52832 firmware project on NCS v3.4.1. After recently moving from NCS v2.9.0 we saw small current spikes every 1s (roughly) in our idle state, which weren't there before.

It was traced to CONFIG_NRF_RTC_COUNTER_BIT_WIDTH, which now defaults to 15 for SOC_NRF52832. With 15 bits the RTC1 counter wraps every second, so the system timer doesn't sleep for as long as it was before.

We've set it back to 24 in our board's Kconfig, and the idle current is back to what we had on NCS v2.9.0.

We'd like to both understand and test this fully (the device is a medical device) and I have a few questions:

1. Why does the nRF52832 default to 15 bits when other nRF52 devices use 24? Is it a workaround for an anomaly?
2. Is 24 bits safe to use on the nRF52832 with the SoftDevice Controller and MPSL? Are there known problems we should test for?

Thanks for your help,

Alex

[Pallavi Patil]

Hi,

Why does the nRF52832 default to 15 bits when other nRF52 devices use 24? Is it a workaround for an anomaly?

The spikes are actually expected. They are caused by a fix for a potential HW bug concerning RTC bit corruption in the nRF52832: For nRF52832, the default RTC bit width is 15 instead of 24. This is related to some RTC bits being possibly corrupted. This could be overridden by changing CONFIG_NRF_RTC_COUNTER_BIT_WIDTH, but the Kconfig is not user-selectable intentionally, counter’s oldest bits may not work properly.

For the default bit width of 15 and RTC prescaler of 0, the counter wrapping happens every 1s. At the same time, RTC driver’s logic limits scheduling to half of counter span because of uint math. Hence, the CPU is awake every 0.5s. The shorter intervals seem like an offset of the one set in main.c, which is in different phase from the steady 0.5s driver’s intervals. 

Is 24 bits safe to use on the nRF52832 with the SoftDevice Controller and MPSL? Are there known problems we should test for?

As a general statement, avoidd using RTC0:on  owns it, so use RTC1 or RTC2 instead. Apart from that you can refer to this link which describes workaround incase RTC register values read invalid after the RTC has been idle. Please let us know if you face any problems while testing so I can bring them up to the team.

Regards

Pallavi

[Alex]

Hi Pallavi, 

Thanks for your response.

In that case, we'll keep the 15-bit default, and have to (unfortunately) accept the higher current consumption compared to before.

Is there an erratum number or link for this on the nRF52832, so I can add it to our FDA risk file please? What does the error look like when it happens? We have some devices already in user trials on NCS v2.9.0 and it would be great to understand the effect of this bug.

Many thanks,

Alex

[Alex]

Digging a little further, I can see the commit in which this was added: 

drivers: timer: nrf_rtc_timer: Allow use of custom bit width

There are no errata listed as part of the commit.

You also mentioned that CONFIG_NRF_RTC_COUNTER_BIT_WIDTH is not user-selectable intentionally; what is the correct way to use the custom bit width that was intended in that commit?

[Pallavi Patil]

Hi,

As seen in the commit, the default value for nRF52832 is 15, and for other Socs its 24. Its a fixed value but not customable. 
I hope this solves your query.

Regards

Pallavi

[Alex]

Hi Pallavi,

I can see that - but what I'm asking is why that is the case? If there's an erratum, or an anomaly in the nRF52832 hardware (but not the other nRF52 variants), I need to know this for our FDA documentation. What is the erratum document or reference number for this?

I'm also confused that you've said the value is not customisable. This seems to directly contradict the commit message "Allow use of custom bit width".

Many thanks,

Alex