PSRAM Free heap memory reduced upon using UART with RTS,CTS Pins set

[mvsrinivasreddy]

Hi,

I am using esp 32 wrover for my project. I have enabled PSRAM to make use of external RAM and set the memory to be automatically allocated as part of the malloc() function call (the default option).

When I initialized my code without UART I used to have the complete free memory which is more than 4 MB (Internal RAM + PSRAM). But, the moment I enable UART initialization, the free memory gradually drops to around 30 KB or less which is clearly only Internal memory.

With below initialization, the free memory of PSRAM is gone.

Code: Select all

#define TXD  (18)
#define RXD  (19)
#define RTS  (17)
#define CTS  (5)

 uart_config_t uart_config = {
        .baud_rate = 115200,
        .data_bits = UART_DATA_8_BITS,
        .parity = UART_PARITY_DISABLE,
        .stop_bits = UART_STOP_BITS_1,
	.flow_ctrl = UART_HW_FLOWCTRL_DISABLE,
	.rx_flow_ctrl_thresh = 122,
    };

    uart_param_config(EX_UART_NUM, &uart_config);
    uart_set_pin(EX_UART_NUM, TXD, RXD, RTS, CTS);

As at trail and error, when I set the PINs as below, free memory is intact.

Code: Select all

uart_set_pin(EX_UART_NUM, TXD, RXD, UART_PIN_NO_CHANGE, UART_PIN_NO_CHANGE);

Can someone please explain the reason? I am guessing one of the reason could be usage of DMA internally for UART which is restricting usage of external memory. But, I don't understand why this would happen when HW_FLOWCTRL is clearly disabled.

[ESP_Angus]

This certainly seems like a memory leak bug. Even if data is being received from the UART (is it?), then there will be an upper limit to the UART buffer size - it shouldn't consume all the available RAM.

What ESP-IDF version are you using?

You can follow the steps here to narrow down the memory leak:
https://docs.espressif.com/projects/esp ... ap-tracing

[ESP_igrr]

#define RTS (17)

GPIO17 is used by PSRAM, and RTS conflicts with that. Please choose a different pin. You can refer to ESP32-WROVER datasheet, pin definition table.

[mvsrinivasreddy]

Sorry for the delayed reply.

I have done the heap tracing as suggested. I can see that the data is being leaked from freertos system calls. I have not done any dynaic memory allocation in my code. Below is the details of the trace. I have only posted the debugging part of the logs.

This is happening with GPIOs 17 and 5 set for RTS and CTS respectively. Is there a possible minor issue causing this to happen? Shouldn't the code throw an error if we are assigning pins for wrong purpose?

This is not a blocker in anyway. But, I would like to know the root cause if possible. Please let me know if further details are required.

ESP IDF version is: 3.1.2

Below are the logs:

bef esp_get_free_heap_size:4340056

UART1 PINS Set
␛[0;32mI (2837) uart: queue free spaces: 10␛[0m
UART1 Driver with Events installed

aft esp_get_free_heap_size:136580

16 allocations trace (100 entry buffer)
248 bytes (@ 0x3ffdbefc) allocated CPU 0 ccount 0x1ac256ac caller 0x4011a9a0:0x400f3de3
84 bytes (@ 0x3ffdbff8) allocated CPU 0 ccount 0x1ac26708 caller 0x4008ed0e:0x4011a9e4
84 bytes (@ 0x3ffdc050) allocated CPU 0 ccount 0x1ac274dc caller 0x4008ed0e:0x4011aa0e
84 bytes (@ 0x3ffdc0a8) allocated CPU 0 ccount 0x1ac28134 caller 0x4008ed0e:0x4011aa27
84 bytes (@ 0x3ffdc100) allocated CPU 0 ccount 0x1ac28d8c caller 0x4008ed0e:0x4008efaf
84 bytes (@ 0x3ffdc158) allocated CPU 0 ccount 0x1ac29a08 caller 0x4008ed0e:0x4008efaf
40 bytes (@ 0x3ffdc1b0) allocated CPU 0 ccount 0x1ac2b55c caller 0x4011972a:0x4011aa7f
164 bytes (@ 0x3ffdc1dc) allocated CPU 0 ccount 0x1ac2c664 caller 0x4008ed0e:0x4011aa98
72 bytes (@ 0x3ffdc284) allocated CPU 0 ccount 0x1acfe8a0 caller 0x4009243e:0x4011ab0a
2048 bytes (@ 0x3ffdc2d0) allocated CPU 0 ccount 0x1acff13c caller 0x40092453:0x4011ab0a
84 bytes (@ 0x3ffdcad4) allocated CPU 0 ccount 0x1acff998 caller 0x4008ed0e:0x40092471
84 bytes (@ 0x3ffdcb2c) allocated CPU 0 ccount 0x1ad0036c caller 0x4008ed0e:0x4009247c
8 bytes (@ 0x3ffc904c) allocated CPU 0 ccount 0x1ad03024 caller 0x400d4362:0x400d45d0
12 bytes (@ 0x3ffc9058) allocated CPU 0 ccount 0x1ad097bc caller 0x400d3f97:0x400d43b4
6000 bytes (@ 0x3ffdcb84) allocated CPU 0 ccount 0x1ad0f3bc caller 0x400904ad:0x400f3dfc
356 bytes (@ 0x3ffc9068) allocated CPU 0 ccount 0x1ad0fcbc caller 0x400904ba:0x400f3dfc
9536 bytes 'leaked' in trace (16 allocations)
total allocations 18 total frees 2

Below is the trace of heap with GDB:

srinivas@srinivas-desktop:~/Desktop/IMSPRIME-ESP32$ ./xtensa-esp32-elf-gdb build/IMSPRIME.elf
Python Exception <type 'exceptions.ImportError'> No module named gdb:
./xtensa-esp32-elf-gdb: warning:
Could not load the Python gdb module from `/builds/idf/crosstool-NG/builds/xtensa-esp32-elf/share/gdb/python'.
Limited Python support is available from the _gdb module.
Suggest passing --data-directory=/path/to/gdb/data-directory.

GNU gdb (crosstool-NG crosstool-ng-1.22.0-80-g6c4433a) 7.10
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=x86_64-build_pc-linux-gnu --target=xtensa-esp32-elf".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from build/IMSPRIME.elf...done.
(gdb) list *0x4008ed0e
0x4008ed0e is in xQueueGenericCreate (/home/srinivas/Desktop/IMSPRIME-ESP32/components/freertos/queue.c:391).
386 /* Allocate enough space to hold the maximum number of items that
387 can be in the queue at any time. */
388 xQueueSizeInBytes = ( size_t ) ( uxQueueLength * uxItemSize ); /*lint !e961 MISRA exception as the casts are only redundant for some ports. */
389 }
390
391 pxNewQueue = ( Queue_t * ) pvPortMalloc( sizeof( Queue_t ) + xQueueSizeInBytes );
392
393 if( pxNewQueue != NULL )
394 {
395 /* Jump past the queue structure to find the location of the queue
(gdb) q
srinivas@srinivas-desktop:~/Desktop/IMSPRIME-ESP32$ ./xtensa-esp32-elf-gdb build/IMSPRIME.elf
Python Exception <type 'exceptions.ImportError'> No module named gdb:
./xtensa-esp32-elf-gdb: warning:
Could not load the Python gdb module from `/builds/idf/crosstool-NG/builds/xtensa-esp32-elf/share/gdb/python'.
Limited Python support is available from the _gdb module.
Suggest passing --data-directory=/path/to/gdb/data-directory.

GNU gdb (crosstool-NG crosstool-ng-1.22.0-80-g6c4433a) 7.10
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=x86_64-build_pc-linux-gnu --target=xtensa-esp32-elf".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from build/IMSPRIME.elf...done.
(gdb) list *0x4011972a
0x4011972a is in uart_pattern_queue_reset (/home/srinivas/Desktop/IMSPRIME-ESP32/components/driver/uart.c:441).
436 esp_err_t uart_pattern_queue_reset(uart_port_t uart_num, int queue_length)
437 {
438 UART_CHECK((uart_num < UART_NUM_MAX), "uart_num error", ESP_FAIL);
439 UART_CHECK((p_uart_obj[uart_num]), "uart driver error", ESP_ERR_INVALID_STATE);
440
441 int* pdata = (int*) malloc(queue_length * sizeof(int));
442 if(pdata == NULL) {
443 return ESP_ERR_NO_MEM;
444 }
445 UART_ENTER_CRITICAL(&uart_spinlock[uart_num]);
(gdb)
446 int* ptmp = p_uart_obj[uart_num]->rx_pattern_pos.data;
447 p_uart_obj[uart_num]->rx_pattern_pos.data = pdata;
448 p_uart_obj[uart_num]->rx_pattern_pos.len = queue_length;
449 p_uart_obj[uart_num]->rx_pattern_pos.rd = 0;
450 p_uart_obj[uart_num]->rx_pattern_pos.wr = 0;
451 UART_EXIT_CRITICAL(&uart_spinlock[uart_num]);
452 free(ptmp);
453 return ESP_OK;
454 }
455
(gdb) list *0x400904ad
0x400904ad is in xTaskCreatePinnedToCore (/home/srinivas/Desktop/IMSPRIME-ESP32/components/freertos/tasks.c:806).
801 #else /* portSTACK_GROWTH */
802 {
803 StackType_t *pxStack;
804
805 /* Allocate space for the stack used by the task being created. */
806 pxStack = ( StackType_t * ) pvPortMallocStackMem( ( ( ( size_t ) usStackDepth ) * sizeof( StackType_t ) ) ); /*lint !e961 MISRA exception as the casts are only redundant for some ports. */
807
808 if( pxStack != NULL )uart_obj[uart_num] = (uart_obj_t*) calloc(1, sizeof(uart_obj_t));

809 {
810 /* Allocate space for the TCB. */
(gdb) q
srinivas@srinivas-desktop:~/Desktop/IMSPRIME-ESP32$ echo $IDF_PATH
/home/srinivas/Desktop/Testidf/esp-idf
srinivas@srinivas-desktop:~/Desktop/IMSPRIME-ESP32$ cd /home/srinivas/Desktop/Testidf/esp-idf
srinivas@srinivas-desktop:~/Desktop/Testidf/esp-idf$ git describe
v3.1.2
srinivas@srinivas-desktop:~/Desktop/Testidf/esp-idf$

[mvsrinivasreddy]

Sorry for my ignorance. The data has been allocated from the system calls and it is not freed yet because the related queues and other buffers are still functional by the time I end the trace.

I think the reduction is memory is instant the moment I assign PSRAM GPIOs to UART driver. May be the gradual reduction is shown as all other system tasks and my application tasks start getting initiated at that point in time.

Only suggestion is to add error check and give warnings when system reserved GPIOs are used for application purposes.

[Ritesh]

Thanks for update regarding that.

We will also take care as we will have a plan to use PSRAM with all UARTs to be used into our application.

Thanks again for that..

[ESP_Angus]

Only suggestion is to add error check and give warnings when system reserved GPIOs are used for application purposes.

Yes, thanks for this suggestion. I've logged this request in our internal issue tracker.