[solved] App hang up on nvs_flash_init()

[shodan8192]

I'm from Poland and this is my first post, so Hello Everyone !

Thanks to rudi from this forum I have Nano32.
I'm using Platformio and i've managed to modify package https://github.com/platformio/platform-espressif32, for successfull built application (in this example it is 02_blink), against latest esp-idf (commit:abecab7).
The problem is that application hang up on nvs_flash_init() - function never return, the tail of verbose output is:

Code: Select all

...
D (390) boot: start: 0x400808e8
I (396) heap_alloc_caps: Initializing heap allocator:
I (404) heap_alloc_caps: Region 19: 3FFB4C14 len 0002B3EC tag 0
I (414) heap_alloc_caps: Region 25: 3FFE8000 len 00018000 tag 1
I (424) cpu_start: Pro cpu up.
I (429) cpu_start: Starting app cpu, entry point is 0x40080a48
I (0) cpu_start: App cpu up.
I (444) cpu_start: Pro cpu start user code
rtc v112 Sep 26 2016 22:32:10
XTAL 40M
I (481) cpu_start: Starting scheduler on PRO CPU.
I (43) cpu_start: Starting scheduler on APP CPU.
D (43) nvs: init start=6 count=3

sometimes with additional garbages.

If instead this code:

Code: Select all

nvs_flash_init();
system_init();
xTaskCreate(&blink_task, "blink_task", 512, NULL, 5, NULL);

I directly call

Code: Select all

blink_task(0);

it works as expected.

Exactly the same effect can be reproduced using MSYS2 environment from https://dl.espressif.com/dl/esp32_win32 ... 160816.zip and latest esp-idf, by set in menuconfig Optimization level to Release, which changes flag for compiler from -Og to -Os, but in Platformio changing this flag had no effect - app built in Platformio always hang on nvs_flash_init, so I think that optimization itself is not source of problem.

I'm not first-class programmer, rather semi-beginner and my guess can be totally wrong, but I think this problem can be related to memory mapping, wrong offset, misalign or overlap, maybe linker scripts need rework - don't know.
Maybe somebody can confirm this weird effect.

Best Regards

[kolban]

I think the first thing to see is if you have a "platformIO" issue or an ESP32 issue. I am assuming you have an Arduino Sketch. Have you tried building the Arduino sketch using the instructions for building Arduino sketches on an ESP32? How does that fare? If it doesn't work, then we have an ESP32 or ESP32/Arduino issue. If it works, then we have a "platformIO" recipe issue. Let's see if we can't pin it down a little further to which of those two possibilities it may be.

[ESP_igrr]

Can you please post the full code to reproduce this?
If this is not possible, is there any chance that you use interrupt handlers in your code, and they are not marked with IRAM_ATTR?

[shodan8192]

@kolban :
i'm not using Arduino framework at all, and the problem exist also for msys2+esp-idf not only Platformio.

@ESP_igrr :
problem reveal even on simple 02_blink code from esp-idf examples.

[ESP_igrr]

Okay, thanks for details. I am sorry i missed that you use "release" optimization level in your first post. It's clear now.

spi_flash driver has a bug which causes it to not work correctly in release mode.
You can work around this by adding 'volatile' qualifier in two lines in components/spi_flash/cache_utils.c, around line 41:

Code: Select all

static volatile bool s_flash_op_can_start = false;
static volatile bool s_flash_op_complete = false;

[shodan8192]

Thank you, i will try this later.
I looked in the cache_utils.c and i see that those variables are used in spinlocks - why from the beginning are not marked as volatile to avoid stuck, caused by compiler optimization ?

[ESP_igrr]

As I said, it's a bug

[shodan8192]

You can work around this by adding 'volatile' qualifier in two lines in components/spi_flash/cache_utils.c, around line 41:

Code: Select all

static volatile bool s_flash_op_can_start = false;
static volatile bool s_flash_op_complete = false;

Ok, it works for building in MSYS2, and Optimization level set to Release.

I still have problem when building in PlatformIO.
Unmodified 02_blink code works, but when i change for example line 36

Code: Select all

vTaskDelay(1000 / portTICK_RATE_MS)

to

Code: Select all

vTaskDelay(100 / portTICK_RATE_MS)

then app hangs. After more digging and LED debugging i found that app is waiting to obtain semaphore in ipc.c
ipc.c:52, function ipc_task

Code: Select all

xSemaphoreTake(s_ipc_sem[cpuid], portMAX_DELAY) <-- wait to obtain semaphore given in esp_ipc_call_and_wait

ipc.c:102, function esp_ipc_call_and_wait

Code: Select all

xSemaphoreGive(s_ipc_sem[cpu_id]); <-- semaphore given
xSemaphoreTake(s_ipc_ack, portMAX_DELAY); <-- wait to obtain ack semaphore that should be given in ipc_task but it never happen

esp_ipc_call_and_wait was called by esp_ipc_call(other_cpuid, &spi_flash_op_block_func, (void*) other_cpuid) from cache_utils.c:96

I have no idea why trivial change in code causing that effect, maybe somebody have a some hint.

[ESP_igrr]

Does the same issue happen in ESP-IDF, with optimization set to release, and delay changed to 100?

[shodan8192]

Does the same issue happen in ESP-IDF, with optimization set to release, and delay changed to 100?

No, in this case app run like it should - i don't get it. I supplied

pio_build.zip

(528.61 KiB) Downloaded 707 times

that contains buildlog from PlatformIO and generated .elf file, maybe i missed something and those files help find solution.