Closed DarkNebula0 closed 8 months ago
do you have the call to mqtt_*
wrapped between cyw43_arch_lwip_begin()
and cyw43_arch_lwip_end()
?
cyw43_arch_lwip_begin
Sorry I was on the road and couldn't test it earlier.
Just tested it, when I call cyw43_arch_lwip_begin I end up with an isr_hardfault
isr_hardfault crt0.S:98
<signal handler called> 0x00000000fffffff9
vtable for __gnu_cxx::stdio_sync_filebuf<char, std::char_traits<char> > 0x00000000100dffc0
async_context_acquire_lock_blocking async_context.h:207
cyw43_thread_enter cyw43_driver.c:153
cyw43_arch_lwip_begin cyw43_arch.h:274
CNetwork::CNetwork Network.h:24
CSingleton::instance Singleton.h:16
__static_initialization_and_destruction_0 Network.cpp:15
_GLOBAL__sub_I_NetworkInstance Network.cpp:150
runtime_init runtime.c:177
platform_entry crt0.S:258
Have you initialise lwip? Have you initialise cyw43?
Have you initialise lwip? Have you initialise cyw43?
´lwip_init´ did the trick.
I am experiencing a system panic on Core 0 of the RP2040 when attempting to initialize the MQTT client using FreeRTOS SMP. The issue arises specifically during the MQTT client initialization process from the lwIP library.
Environment: Hardware: pico_w OS: FreeRTOS SMP Library: lwIP <lwip/apps/mqtt.h>
Linked Libraries
Stack Trace:
Detailed Description: The panic occurs when I call mqtt_client_new() from
lwip/apps/mqtt.h
This function eventually calls mem_malloc from pico-sdk\lib\lwip\src\core\mem.c
, which in turn calls sys_mutex_lock. The failure happens with an LWIP_ASSERT, specificallyLWIP_ASSERT("mutex->mut != NULL", mutex->mut != NULL);
.All actions leading to the panic are executed on core 0, which suggests an issue with mutex handling in a multi-core environment or a misconfiguration.
Steps to Reproduce: Initialize the RP2040 with FreeRTOS SMP. Call mqtt_client_new() to initialize the MQTT client. Observe the panic on core 0 during the execution of sys_mutex_lock.
FreeRTOSConfig.h
lwipopts.h