getting NRF_LIBUARTE_ASYNC_EVT_OVERRUN_ERROR after long time of use

[Roy@techpacklab]

Hello,

im using nrf52840 with sd140 and sdk17.0.1

in my project i have implemented a libuarte communication that works well usually, but rarely, and usually after days of running i get this error:

NRF_LIBUARTE_ASYNC_EVT_OVERRUN_ERROR

i do nothing to handle this error and continue regularly and after this i start getting jumbled strings from the libuarte.

meaning if i send something like this:

"

123456789

123456789

123456789

123456789

abcdefghijklmnopqrstvuwxyz

"

i might get something like this:

"

123456789\n

123456789\n

123456789\n

123456789\n

abcdefghijklm123456789\n

nopqrstvuwxyz

"

i have seen a similar question in the following link:

https://devzone.nordicsemi.com/f/nordic-q-a/63905/libuarte-issue-nrf_balloc_alloc-retuns-null-after-a-while

and it ended up in saying that it got resolved somehow with the timers, which i kind of suspected,  but still don't know how to resolve.

i init the libuarte by:

NRF_LIBUARTE_ASYNC_DEFINE(xxxxx_libuarte0, 0, 1, 2, NRF_LIBUARTE_PERIPHERAL_NOT_USED, ATCMD_LIBUARTE0_RX_BUF_SIZE, ATCMD_LIBUARTE0_RX_BUF_CNT);    // using uart0 ; TIMER1; RTC2

this problem is very rare which makes it difficult to debug. 

please advise,

Regards,

Roy Barak

TechPack Lab

[Simonr]

Hi Roy

This could indeed be a conflict with your timers. Please check that the other peripherals you're using in your application does not use the same TIMER instance(s) as your libuarte peripheral or alternatively try changing the timer you're using for libuarte now to see if you still see this error.

After multiple days of runtime there could also be clock drift I guess, and you could try to handle this error by trigging a reset of the chip for instance, if that won't cause problems for your application.

Best regards,

Simon

[Roy@techpacklab]

Hi Simon,

Thanks for the reply, a couple of followup questions:

1. i have looked again if anyone else is using either the timer1 or RTC2 and i cant see that any other peripheral does.

to make sure i also commented the enable from them in the sdk_config.h and compiled, (after changing the libuarte to use others) and the compilation passed.

i assume that it is still possible that some peripheral is still using one of them but simply there was no check fr the compilation, my code started from the "ble_app_interactive" example, do you know if anything there might be using either the RTC2 or TIMER1?

Regarding the peripherals i added, it is more easy for me to check and i do not see any use in either of them.

2. in case of a drift, i will do a reset if i have no other choice, but it does disturb the operation of the system so i rather now. what other options i have to handle possible drift?:

a. is there a preference for using TIMER2 or RTC2 ? meaning do you think one of them might be more sensitive to drift than the other?

b. my HW is Fanstel module BT840X and i am using an external 32Khz crystal. is there a configuration that i might miss?

the current configuration in the SDK config is:

"
// <0=> RC
// <1=> XTAL
// <2=> Synth
// <131073=> External Low Swing
// <196609=> External Full Swing

#ifndef CLOCK_CONFIG_LF_SRC
#define CLOCK_CONFIG_LF_SRC 1
#endif

// <q> CLOCK_CONFIG_LF_CAL_ENABLED - Calibration enable for LF Clock Source

#ifndef CLOCK_CONFIG_LF_CAL_ENABLED
#define CLOCK_CONFIG_LF_CAL_ENABLED 0
#endif

"

"

//==========================================================

// <h> Clock - SoftDevice clock configuration

//==========================================================
// <o> NRF_SDH_CLOCK_LF_SRC - SoftDevice clock source.

// <0=> NRF_CLOCK_LF_SRC_RC
// <1=> NRF_CLOCK_LF_SRC_XTAL
// <2=> NRF_CLOCK_LF_SRC_SYNTH

#ifndef NRF_SDH_CLOCK_LF_SRC
#define NRF_SDH_CLOCK_LF_SRC 1
#endif

// <o> NRF_SDH_CLOCK_LF_RC_CTIV - SoftDevice calibration timer interval.
#ifndef NRF_SDH_CLOCK_LF_RC_CTIV
#define NRF_SDH_CLOCK_LF_RC_CTIV 0
#endif

// <o> NRF_SDH_CLOCK_LF_RC_TEMP_CTIV - SoftDevice calibration timer interval under constant temperature.
// <i> How often (in number of calibration intervals) the RC oscillator shall be calibrated
// <i> if the temperature has not changed.

#ifndef NRF_SDH_CLOCK_LF_RC_TEMP_CTIV
#define NRF_SDH_CLOCK_LF_RC_TEMP_CTIV 0
#endif

// <o> NRF_SDH_CLOCK_LF_ACCURACY - External clock accuracy used in the LL to compute timing.

// <0=> NRF_CLOCK_LF_ACCURACY_250_PPM
// <1=> NRF_CLOCK_LF_ACCURACY_500_PPM
// <2=> NRF_CLOCK_LF_ACCURACY_150_PPM
// <3=> NRF_CLOCK_LF_ACCURACY_100_PPM
// <4=> NRF_CLOCK_LF_ACCURACY_75_PPM
// <5=> NRF_CLOCK_LF_ACCURACY_50_PPM
// <6=> NRF_CLOCK_LF_ACCURACY_30_PPM
// <7=> NRF_CLOCK_LF_ACCURACY_20_PPM
// <8=> NRF_CLOCK_LF_ACCURACY_10_PPM
// <9=> NRF_CLOCK_LF_ACCURACY_5_PPM
// <10=> NRF_CLOCK_LF_ACCURACY_2_PPM
// <11=> NRF_CLOCK_LF_ACCURACY_1_PPM

#ifndef NRF_SDH_CLOCK_LF_ACCURACY
#define NRF_SDH_CLOCK_LF_ACCURACY 7
#endif

// </h>

"

Regards,

Roy Barak.

[Simonr]

Hi again,

1. No, the ble_app_interactive example should not use TIMER1 or RTC2 by default.

2. Are you using HWFC in your application? You can do so by setting the NRF_LIBUARTE_DRV_HWFC_ENABLED flag. Enabling HWFC will pause transmissions and restore it once the buffer is available, so you could try that. 

2a. Neither should be very prone to drifting if the crystal they use are configured correctly. Can you provide the datasheet of the LF crystal you're using in your application, and the values of the load capacitors you're using?

2b. The configuration seems to be okay, you can try tweaking the NRF_SDH_CLOCK_LF_ACCURACY a bit to see if that makes a difference, even though 20 PPM should be okay as long as the crystal you're using supports it.

Best regards,

Simon

[Roy@techpacklab]

Hi Simon,

the crystal i used is 9pf 20ppm accuracy:

CM7V-T1A-32.768k-9pF-20PPM-TA-QA T3

i have 12pf caps for it to compensate for 2-3pf estimated pcb capacitance.

(and as mentioned i also see this bug when using fanstel BT840X board which has basically the same clock schem)

i have tried also to make a version with the following changes:

- libuarte will use TIMER1 and TIMER2 instead of TIMER1 and RTC2 

- set the LF accuracy to 0 (NRF_CLOCK_LF_ACCURACY_250_PPM)

after a few days in load i saw the bug again.

will try enabling NRF_LIBUARTE_DRV_HWFC_ENABLED  for the next version.

but other than that, im in a bit of a loss, do you have any other possible solutions?

Best regards,

Roy.

[Simonr]

Hi Roy

Indeed, your crystal (and capacitors) seem to be okay. I have asked internally if anyone have any other ideas, but the most likely issue seems to be that the HWFC is not enabled here.

Best regards,

Simon