micro_ros_espidf_component ESP32 crashes when listening_message

ESP32 crashes when listening_message_reliably

Hardware description: ESP32 serially linked to a nRF5340DK (using UART1 on pins 19/18 as TX/RX)
RTOS: FreeRTOS
Installation type: micro_ros_espidf_component, ESP IDF v4.4
Version or commit hash: humble

Steps to reproduce the issue

My project consist on controlling a BT Mesh provisioner via ROS, and transmitting sensors data from the Mesh network to ROS. The ESP32 serves as a message bridge between the provisioner and ROS. For that I've got 4 threads running :

the uROS thread (priority 5, stack 16000 bytes) with 2 subs and 2 pubs
an "uart_phy" thread (priority 6, stack 4096 bytes) which job is to read data from UART1 and sends it to uart_mac_rx with a message queue
2 "uart_mac_rx" and "uart_mac_tx" threads (priority 6, stack 4096 bytes). uart_mac_rx gets data from uart_phy and publishes message to ROS. uart_mac_tx receives messages from the subscribers callbacks and transmits data to UART1

The nRF5340 scans for unprovisioned ("unconnected") mesh nodes, and sends the UUIDs to the ESP32 via serial. So the ESP32 receives a 16 bytes UUID from UART, the uart_phy sends this UUID to uart_mac_rx through a message queue. uart_mac_rx wakes up because something is in the queue, sees that it is an UUID, and publish it with my "unprov_pub". The ROS message is the following : ble2ros_interfaces/msg/Beacon.msg

# Represent an unprovisioned beacon from BT Mesh
uint8[16] uuid

Expected behavior

UUIDs are sent to ROS without error

Actual behavior

Sometimes, mostly when the ESP32 receives a lot of UUID's to transmit to ROS, i got the following error : assert failed: pbuf_free IDF/components/lwip/lwip/src/core/pbuf.c:757 (pbuf_free: p->ref > 0) OR assert failed: tlsf_free heap_tlsf.c:872 (!block_is_free(block) && "block already marked as free")

but mostly the pbuf_free assert failed. The most frequent stack backtrace is the following :

assert failed: pbuf_free IDF/components/lwip/lwip/src/core/pbuf.c:757 (pbuf_free: p->ref > 0)

Backtrace:0x40081ade:0x3ffd0a700x400891bd:0x3ffd0a90 0x4008fd5d:0x3ffd0ab0 0x400f3de7:0x3ffd0bd0 0x401057c1:0x3ffd0bf0 0x400f03ef:0x3ffd0c10 0x400f0ff2:0x3ffd0c50 0x400f1072:0x3ffd0cb0 0x400de19d:0x3ffd0cd0 0x400ddfad:0x3ffd0d00 0x400dd2fc:0x3ffd0d30 0x400dd488:0x3ffd0dd0 0x400e2836:0x3ffd0df0 0x400e0e4b:0x3ffd0e40 0x400da51d:0x3ffd0eb0 0x400da563:0x3ffd0ef0 0x400d6e6c:0x3ffd0f10 0x400d6e7e:0x3ffd0f30 0x4008c37d:0x3ffd0f50 
0x40081ade: panic_abort at /home/samy/esp/esp-idf/components/esp_system/panic.c:402
0x400891bd: esp_system_abort at /home/samy/esp/esp-idf/components/esp_system/esp_system.c:128
0x4008fd5d: __assert_func at /home/samy/esp/esp-idf/components/newlib/assert.c:85
0x400f3de7: pbuf_free at /home/samy/esp/esp-idf/components/lwip/lwip/src/core/pbuf.c:757 (discriminator 1)
0x401057c1: netbuf_delete at /home/samy/esp/esp-idf/components/lwip/lwip/src/api/netbuf.c:85
0x400f03ef: lwip_recvfrom_udp_raw at /home/samy/esp/esp-idf/components/lwip/lwip/src/api/sockets.c:1250
0x400f0ff2: lwip_recvfrom at /home/samy/esp/esp-idf/components/lwip/lwip/src/api/sockets.c:1292 (discriminator 4)
0x400f1072: lwip_recv at /home/samy/esp/esp-idf/components/lwip/lwip/src/api/sockets.c:1337
0x400de19d: uxr_read_udp_data_platform at ??:?
0x400ddfad: recv_udp_msg at udp_transport.c:?
0x400dd2fc: listen_message_reliably at session.c:?
0x400dd488: uxr_run_session_until_data at ??:?
0x400e2836: rmw_wait at ??:?
0x400e0e4b: rcl_wait at ??:?
0x400da51d: rclc_executor_spin_some$part$5 at executor.c:?
0x400da563: rclc_executor_spin_some at ??:?
0x400d6e6c: spin_uros at /home/samy/work/ble2ros/firmware/uros_node/main/uros/uros.c:119 (discriminator 1)
0x400d6e7e: uros_task at /home/samy/work/ble2ros/firmware/uros_node/main/uros/uros.c:126
0x4008c37d: vPortTaskWrapper at /home/samy/esp/esp-idf/components/freertos/port/xtensa/port.c:131

Additional information

I also had other configuration with at most 4 pubs and 4 subs, and this problem can occur with any publisher. I went back to 2 pubs and 2 subs to get back to the basic uROS config (also resetted the max pub/sub in colcon.meta)

I looked if the heap became corrupted at some point, but it was always clean.

When disabling asserts, it stills crash with Guru meditation error: Core 0 panic'ed

I tried lowering priorities, (12 for UART, 11 for uROS), switching priorities (4 for UART, 5 for uROS), still got the same problem.

Looked over the internet for solutions, looked in this repo's issues, found nothing...

Looked if I had memory leaks, but found none

Aug 06 '22 15:08 SamyFrancelet

What are the differences between the uROS thread and "uart_mac_rx" and "uart_mac_tx" threads? Are you calling the micro-ROS API from two different threads? Have you enabled the multithread operation of the middleware?

In any case, a corruption like this sounds to me like a stack overflow. Have you tried to increase stack sizes of each task?

Aug 08 '22 05:08 pablogs9

Here is a quick diagram showing how to program is composed :

uros_node

Every subs run with the uros_thread executor, their callback functions sends a message to the txQueue. uart_mac_rx receives messages from the uart_phy thread and calls the rcl_publish, so yeah it uses the micro-ROS API.

I already tried increasing stacks, but maybe not enough. I'll try both propositions

Aug 08 '22 06:08 SamyFrancelet

Ok, please provide feedback. And enable the multithread flag because if not, all the stack layers are not thread safe!

Aug 08 '22 06:08 pablogs9

When I turn ON the UCLIENT_PROFILE_MULTITHREAD in the CMakeLists.txt of Micro-XRCE-DDS-Client, it doesn't change the build, and when I do a clean build, it reverts back to OFF. Am I missing something ?

Aug 08 '22 07:08 SamyFrancelet

You need to use the colcon.meta file in order to confgure the micro-ROS stack.

Aug 08 '22 07:08 pablogs9

I have added the line "-DUCLIENT_PROFILE_MULTITHREAD=ON" in microxrcedds_client/cmake-args in colcon.meta, but it stays off in the CMakeLists.txt

Aug 08 '22 07:08 SamyFrancelet

Just check that is enabled in the generated config.h inside Micro XRCE-DDS Client include folder

Aug 08 '22 07:08 pablogs9

Just a moment, my build keeps crashing (doesn't find <rcl/rcl.h> and micro-ros doesn't want to clean)

Aug 08 '22 07:08 SamyFrancelet

When I set the line in colcon.meta, the build keeps crashing