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

[Roy@techpacklab]

Hi Simon,

i have some update, in the latest version i have enabled the HWFC and the bug also returned, although it took much more time and attempts to reproduce the bug (over a week when before it took 2-4 days top).

i do not know if this has something to do with the HWFC enabling or just a fluke (as this is a rare bug to begin with), we are running this again to get a better statistic.

do you have any thought if the enabling of the HWFC might only solve this sometimes?

if so, do you have a solution to the remainder?

any other ideas?

if this will not be solved, then we will need to find acceptable bypass solutions, the simplest one is reset, but for the system it might complicate things, can you suggest a cleaner solution? possibly resetting only the libuarte and re-init it will work?

Regards,

Roy.