Simultaneous communication on 2 sync libUARTe

RE: Simultaneous communication on 2 sync libUARTe

Susheel Nuguru — Mon, 09 Sep 2024 21:47:49 GMT

[quote user="Vojko Glaser"]What is the best way to check memory consumption (analitically or real-life)? The solution with printing address of NULL pointer variable always returns the same address from which we are not able to detect if memory consumption is growing. Any other way to detect memory leaks? Or to at least detect that memory leak is present?[/quote]

This is never straightforward. But I once followed this long time ago on FreeRTOSv9 with some success. I do not remember the details but I bookmarked this page as it was helpful.

[quote user="Vojko Glaser"]And to check it analytically. Soft_device will take a part of memory, freertos heap will be next and in the end malloc calls, right? If there is enough space malloc should not intervene in the memory locations of other two, right? It should return NULL.[/quote]

Yes, if there are no stack overflows, then the memory used by softdevice or application should not split into using the reserved heap area.

RE: Simultaneous communication on 2 sync libUARTe

Vojko Glaser — Thu, 05 Sep 2024 07:55:36 GMT

Hi.

Unfortunately, we have a custom board and it would probably take a lot of changes to test it on DK. We will try to make a DK version.

But in the mean time. We do use malloc and free. Would it make sense to use pvPortMalloc from freertos (heap_3 variant) or even nrf_malloc to prevent memory corruption?

What is the best way to check memory consumption (analitically or real-life)? The solution with printing address of NULL pointer variable always returns the same address from which we are not able to detect if memory consumption is growing. Any other way to detect memory leaks? Or to at least detect that memory leak is present?

And to check it analytically. Soft_device will take a part of memory, freertos heap will be next and in the end malloc calls, right? If there is enough space malloc should not intervene in the memory locations of other two, right? It should return NULL.

RE: Simultaneous communication on 2 sync libUARTe

Susheel Nuguru — Thu, 05 Sep 2024 04:15:11 GMT

Hi,

Is this reproducible on nRF52833 DK? If yes, can you please share the project so that I can attempt to start the debugger and figure out the context of the fault. Seems like there is some stack corruption here.

RE: Simultaneous communication on 2 sync libUARTe

Vojko Glaser — Tue, 03 Sep 2024 08:59:34 GMT

For example:

HARD FAULT at 0x0004EE9A

R0: 0x20009E60 R1: 0x2001B670 R2: 0x054E022D R3: 0x054E022D

R12: 0x2000ED44 LR: 0x0004EE71 PSR: 0x81000000

and from .map

.text 0x000000000004ee54 0xc4 /usr/lib/gcc/arm-none-eabi/10.3.1/../../../arm-none-eabi/lib/thumb/v7e-m+fp/hard/libc_nano.a(lib_a-nano-freer.o)
0x000000000004ee54 _free_r
.text 0x000000000004ef18 0xb4 /usr/lib/gcc/arm-none-eabi/10.3.1/../../../arm-none-eabi/lib/thumb/v7e-m+fp/hard/libc_nano.a(lib_a-nano-mallocr.o)
0x000000000004ef18 _malloc_r

RE: Simultaneous communication on 2 sync libUARTe

Vojko Glaser — Tue, 03 Sep 2024 08:25:04 GMT

Hi.

Thanks for the response.

Just to double check if we understood you correctly.

1. You're suggesting not to used async library (nrf_libuarte_async) and work only with low level libuarte driver (nrf_libuarte_drv)? Because according to the docs, if you are using app_timer RTC is not used. Or is there another option to disable receiver timeout we have missed?

2. If we checkout the address from .map that the hardfault is reffering to (pc), always comes from malloc(_malloc_r) or free (_free_r) source file. Any good suggestions how to backtrace the origin of the failure?

RE: Simultaneous communication on 2 sync libUARTe

Susheel Nuguru — Thu, 29 Aug 2024 10:38:38 GMT

Just thinking out loud here. Async UART lib is a bit of resource hungry in the sense that it uses TIMER and RTC if inactivity timeout is used. If you are using tw libuarte then you aer using atleast two high resolution timers and maybe two additional RTCs if you are using inactivity timeout for receiver. Also note that FreeRTOS needs RTC1 (instance is configurable). So it looks like it might be very easy to get into a resource conflict using two libuarte on FreeRTOS. My suggestions are

Disable receiver timeout functionality and make sure RTC is not used in libUARTE. This will avoid any RTC resource conflicts I think might be happening with FreeRTOS RTC instance and your libuarte.
Debug your hardfault first. Get the exact hardfaulting instruction. Maybe what you are seeing is just a stack overflow error caused by under defining the task stack size.

RE: Simultaneous communication on 2 sync libUARTe

Vojko Glaser — Wed, 28 Aug 2024 19:55:13 GMT

To elaborate further here is our uarte handler:

void uarte_event_handler(void * context, nrf_libuarte_async_evt_t * p_evt){

switch (p_evt->type){

case NRF_LIBUARTE_ASYNC_EVT_RX_DATA:

{

NRF_LOG_ERROR("uarte: EVT_RX - data received");

BaseType_t yield = pdFALSE;

BaseType_t sent = errQUEUE_FULL;

uart_queue_data_t data;

data.length = p_evt->data.rxtx.length;

data.p_data = p_evt->data.rxtx.p_data;

sent = xQueueSendFromISR(stm_uart_rx_queue, &data, &yield);

if(sent != pdTRUE){

NRF_LOG_ERROR("uarte: queue full");

}

portYIELD_FROM_ISR(yield);

} break;

case NRF_LIBUARTE_ASYNC_EVT_TX_DONE:

{

BaseType_t yield = pdFALSE;

xEventGroupSetBitsFromISR(stm_uart_tx_event_h, 0x01, &yield);

portYIELD_FROM_ISR(yield);

} break;

case NRF_LIBUARTE_ASYNC_EVT_ERROR:

NRF_LOG_ERROR("uarte: error %d", p_evt->data.errorsrc);

break;

case NRF_LIBUARTE_ASYNC_EVT_OVERRUN_ERROR:

NRF_LOG_ERROR("uarte: overrun: lost %d", p_evt->data.overrun_err.overrun_length);

break;

default:

NRF_LOG_ERROR("uarte: wrong state");

break;

}

nrf_libuarte_async_rx_free is called in the task fetching data from the queue. UART baudrate is 115200 with hardware flow control disabled:

nrf_libuarte_async_config_t nrf_libuarte_async_config = {

.tx_pin = UARTE_TX_PIN,

.rx_pin = UARTE_RX_PIN,

.baudrate = NRF_UARTE_BAUDRATE_115200,

.parity = NRF_UARTE_PARITY_INCLUDED,

.hwfc = NRF_UARTE_HWFC_DISABLED,

.timeout_us = 100,

.int_prio = APP_IRQ_PRIORITY_LOW

};