libuarte_async idle detection using hardware timer and power consumption

[droberson]

Hardware: nRF52840 custom board

Software:

SDK: nRF5_SDK_17.0.2_d674dde

Using FreeRTOS where #define configTICK_SOURCE FREERTOS_USE_RTC  (Using RTC as systick)

2 UART's using libuart_async to achieve 921600 baud

RTC0: SoftDevice

RTC1: FreeRTOS Systick

RTC2: Time keeping counter (Overflow event tied to Hardware Timer 1 in counter mode for overflow count)

Timer0: SoftDevice

Timer1: Counts RTC2 overflows for time keeping purposes

Timer2: NRF_LIBUARTE_DRV_UARTE0

Timer3: NRF_LIBUARTE_DRV_UARTE1

Timer4: Not used

Hello,

From my understanding, I see that libuarte_async supports idle line detection using one of the following timers:

• Hardware Timer
• RTC
• App timer

Question 1: If a hardware timer is used for timeout (idle line detection), is the timer always running or does it only run while data is being received and then stop when a timeout occurs? My concern here is that hardware timers use the HFCLK and I wouldn't want the HFCLK running when no UART data is being received.

Question 2: How do you recommend I configure my timers for lowest power consumption?

I don't have enough free timers (RTC or HW Timer). App timer is inefficient because it always triggers a timeout event at the configured interval regardless if RX data is being received.

Question 3: Is it possible to use the same RTC for FreeRTOS Systick and system time counting? I don't see why I can't free up RTC2 by counting the overflow events of RTC1 and share RTC1 with FreeRTOS. I don't want to interfere with the functions of tickless idle and such though so I am not sure this is possible? If possible, I can then use RTC2 for UARTE0 timeout and Timer4 for UARTE1 timeout.

Thanks,

Derek

[ovrebekk]

Hi 

Sorry for the slow response Derek. I only work part time this week, and whenever I am online the developer seems to evade me. I will do my best to get you a response to all your questions tomorrow. 

droberson said:

So I have to tell the modem I am about to send it a chunk of data using AT#SSENDEXT=1,1000, wait for the ">" character to be returned, then send it the data, and wait for "OK" to be returned.

There should be some way to manually poll the driver at the point in time when you expect the OK status to be returned, so you don't have to wait for the driver to timeout. At least if the delay between the peer receiving the command and returning OK is somewhat consistent?

As I said I will try to provide a more detailed response tomorrow. 

Best regards
Torbjørn

[ovrebekk]

Hi Derek

I got a hold of the developer, and he confirmed that there is no power management built into the driver unfortunately, but according to him it should be possible to add a wrapper around the library to implement something like this. 

You might also consider the lpuart driver in NCS, which is a wrapper around the standard async UART interface that adds two flow control lines in order to optimize power consumption. 

You can read more about this driver here.

Best regards
Torbjørn 

[droberson]

Hey Torbjørn,

Thanks for the info. I'll take a look at that. Looks like it's for the nrfConnect SDK using Zephyr RTOS but the flow control methodology still applies. In our next spin of our board we will add some extra GPIO between processors for our UART IPC interface and do something similar for low power.

Derek