Thalhammer
commented
5 months ago So I did some digging on this and the reason why the app isn't initialized (and the image is so small) is that there are a bunch of places where important code is placed inside an assert. Enabling NDEBUG turns those into noops and stuff obviously goes down the drain from there. I did a quick grep/scan of the codebase and those are the instances I could find where this presents an issue:
// components/esp8266/source/startup.c:72: assert(base_gpio_init() == 0);
// components/esp8266/source/startup.c:75: assert(esp_mac_init() == ESP_OK);
// components/esp8266/source/startup.c:86: assert(esp_pthread_init() == 0);
// components/esp8266/source/startup.c:163: assert(__esp_os_init() == 0);
// components/esp8266/source/startup.c:166: assert(esp_newlib_init() == 0);
// components/esp8266/source/startup.c:168: assert(xTaskCreate(user_init_entry, "uiT", ESP_TASK_MAIN_STACK, NULL, ESP_TASK_MAIN_PRIO, NULL) == pdPASS);
// components/wifi_provisioning/src/manager.c:38:#define ACQUIRE_LOCK(mux) assert(xSemaphoreTake(mux, portMAX_DELAY) == pdTRUE)
// components/wifi_provisioning/src/manager.c:39:#define RELEASE_LOCK(mux) assert(xSemaphoreGive(mux) == pdTRUE)
// components/wifi_provisioning/src/manager.c:624: assert(xTaskCreate(prov_stop_task, "prov_stop_task", 4096, (void *)1,
// components/bootloader_support/src/bootloader_sha.c:36: assert(mbedtls_sha256_starts_ret(ctx, false) == 0);
// components/bootloader_support/src/bootloader_sha.c:44: assert(mbedtls_sha256_update_ret(ctx, data, data_len) == 0);
// components/bootloader_support/src/bootloader_sha.c:52: assert(mbedtls_sha256_finish_ret(ctx, digest) == 0);
// components/bootloader_support/src/bootloader_sha.c:194: assert(mbedtls_sha256_starts_ret(ctx, false) == 0);
// components/bootloader_support/src/bootloader_sha.c:202: assert(mbedtls_sha256_update_ret(ctx, data, data_len) == 0);
// components/bootloader_support/src/bootloader_sha.c:210: assert(mbedtls_sha256_finish_ret(ctx, digest) == 0);
// components/esp_ringbuf/ringbuf.c:1066: configASSERT(xSemaphoreGive(pxRingbuffer->xItemsBufferedSemaphore) == pdTRUE);
// components/esp_ringbuf/ringbuf.c:1092: configASSERT(xSemaphoreGive(pxRingbuffer->xItemsBufferedSemaphore) == pdTRUE);
// components/esp_ringbuf/ringbuf.c:1160: configASSERT(xSemaphoreGive(pxRingbuffer->xFreeSpaceSemaphore) == pdTRUE);
// components/esp_ringbuf/ringbuf.c:1179: configASSERT(xSemaphoreGive(pxRingbuffer->xFreeSpaceSemaphore) == pdTRUE);However: These are only the ones I could find on a basic scan, have no idea if this list is complete.
The most relevant for this issue are the ones in startup.c. The ones in wifi_provisioning are only relevant if you use it, same applies to the ones in bootloader_sha (which will break secure boot). The last ones in ringbuf.c break esp_ringbuf, but I am unsure where thats used.
I went ahead and fixed all of those (patch) and once thats done everything works correctly when NDEBUG is enabled (you also don't need the ld change anymore because now the image is big enough not to trigger that error). I then compiled my app twice, once with NDEBUG, once with silent asserts.
No NDEBUG
Memory region Used Size Region Size %age Used
iram0_0_seg: 26148 B 48 KB 53.20%
iram0_2_seg: 420640 B 491504 B 85.58%
dram0_0_seg: 10840 B 96 KB 11.03%
rtc_data_seg: 0 GB 512 B 0.00%
NDEBUG
Memory region Used Size Region Size %age Used
iram0_0_seg: 26148 B 48 KB 53.20%
iram0_2_seg: 390180 B 491504 B 79.38%
dram0_0_seg: 10840 B 96 KB 11.03%
rtc_data_seg: 0 GB 512 B 0.00%Enabling NDEBUG shrunk the image by about 7% (30k), which is about what I'd expect. However you are now at the risk of hitting some assert bug that I didn't find. So unless you've run out of other stuff you can disable to reduce that size I wouldn't touch NDEBUG, even with my patch applied. If you do, make sure you retest all functions of your app to make sure it still works correctly.
I hope this helps anyone.
Environment
Problem Description
Application doesn't work as expected when assertion level is set to "disabled" in menuconfig.
Expected Behavior
It should be possible to disable assertions and to have working application.
Actual Behavior
When assertion level is set to "disabled" in menuconfig, first we get linking error, which can be solved by using workaround from https://github.com/espressif/ESP8266_RTOS_SDK/issues/1260#issuecomment-1818806487
After fixing the linking problem, application build and flash successfully, however it doesn't work as expected. There are only logs visible from bootloader and then app hangs. I tried with "hello_world" example which prints on cosole and restart module evey 10 s. With assetions disabled there is no single log output and there is no restart visible at all.
Steps to repropduce
Code to reproduce this issue
hello_world example
Debug Logs
Only below log is printed. Nothign in printed from application itself. There is no ESP reset visible at all (there should be repeated bootloader log every ~10 s in hello_world example).