Strictly necessary cookies are on by default and cannot be turned off. Functional, Performance and Tracking/targeting/sharing cookies can be turned on below based on your preferences (this banner will remain available for you to accept cookies). You may change your cookie settings by deleting cookies from your browser. Then this banner will appear again. You can learn more details about cookies HERE.
Strictly necessary (always on)
Functional, Performance and Tracking/targeting/sharing (default off)
We are using a STM32L562 with a Type1 DX Murata (BCM4343W) Wi-Fi/BT chip module. OS is FreeRTOS v10.2.1, using WICED v6.4 and network stack is LwIP.
Our main application sends 1 UDP frame per second to a DTLS server (we use mbedtls). On reception of those frames, the DTLS sever sends back a UDP frame for acknowledge. Data payload of received frame is 65 bytes.
We have noticed that some Wi-Fi router from internet service provider transmitted our "acknowledge" UDP frame not on a period of one every second but up to 12 in a period of 5ms.
(see wireshark_udp_burst.png, whole wireshark capture can be sent directly by e-mail if needed)
However, such behavior causes our board to crash following a memory allocation issue.
We trace the allocation process from the function wiced_packet_create_udp() to the memp_malloc()/pbuf_alloc() functions which are the functions returning in error.
When monitoring network with the LwIP stats, we can see that the fields "MEM PBUF_POOL_RX err" keeps increasing until our board crashes (see memory_trace.log, only link, udp and mem stats are displayed). Increasing the number PBUF_POOL_RX is not a solution. It may delay the board resets but does not solve our issue as our RAM memory does not allow us to go higher than 12 and that more than 12 UDP packets can be send in a row.
We try to change some configuration to resolve the issue, without success so far:
- disabling Wi-Fi chip powersaving mode
- using FreeRTOS heap4 and use FreeRTOS allocation functions for alloc/free functions of LwIP
Our concern is why this configuration of receiving a dozen of UDP packets in a few milliseconds causes memory allocation issue ? Is this a memory leak ?
Can you help us find the root cause of this leak ?