vTaskDelay in a global constructor causes: Guru Meditation Error: Core 0 panic'ed (LoadProhibited). (IDFGH-13727)

[mmirad]

Answers checklist.

• I have read the documentation ESP-IDF Programming Guide and the issue is not addressed there.
• I have updated my IDF branch (master or release) to the latest version and checked that the issue is present there.
• I have searched the issue tracker for a similar issue and not found a similar issue.

IDF version.

v5.3 and
v5.3.1-244-g4d0db7045d

Espressif SoC revision.

ESP32-WROVER (With ESP_PROG)

Operating System used.

Windows

How did you build your project?

Eclipse IDE

If you are using Windows, please specify command line type.

None

Development Kit.

Power Supply used.

USB

What is the expected behavior?

Call the constructor in the global region and continues with the program

What is the actual behavior?

The device is continuous restarting:

Guru Meditation Error: Core 0 panic'ed (LoadProhibited). Exception was unhandled.

Steps to reproduce.

1. Create a constructor with the function vTaskDelay inside the constructor.
2. Call the constructor as global.
3. The constructor are created before the main and after enter in the vTaskDelay crash: Guru Meditation Error: Core 0 panic'ed (LoadProhibited). Exception was unhandled.

Debugger stops on before crash:

Debug Logs.

More Information.

In the version 4.3 this configurations works well.

No response

[sudeep-mohanty]

Hi @mmirad, It maybe possible that the constructor is called even before the scheduler has started. This would mean that several kernel objects may not have been created yet and it could result in the error that you see. Could you provide some information about where or how is the constructor getting called in your application?

[mmirad]

Here is a small sample of my code with the parts that affect this.

ADC adc1(k_adc1_instance);
void my_main (void)
{
	// my code
	adc1.init()
	adc1.init_chanel();

	while(1)
	{
		// rest of the code
	}
}

#include <stdio.h>
#include "freertos/FreeRTOS.h"
#include "freertos/task.h"
#include "my_main.h"
void app_main(void)
{
    my_main();

    // This code should never be reached
    while (1)
    {
        vTaskDelay(1000 / portTICK_PERIOD_MS);
    }
}

ADC::ADC(uint8_t adc_instance) : m_supported(false), m_initialized(false), m_channels_num(0)
{

    printf("ADC#%hhu: CONSTRUCTOR\r\n", adc_instance);
    vTaskDelay(pdMS_TO_TICKS(ms));
	// set channels....
}

Just remember that the same code for version 4.3 works correctly, what could be the reason?

[sudeep-mohanty]

@mmirad Thanks for the code snippet. The issue arrises because the vTaskDelay() is called outside of a task context and before the full RTOS environment is setup. The FreeRTOS kernel can't handle this scenario. FreeRTOS can only delay tasks but cannot deal with a constructor getting "delayed" outside of a task scope. The same would happen if you call vTaskDelay() from an ISR context. I haven't looked at why the call worked in 4.3 yet but it could have been a coincidence that it worked.
Nevertheless, maybe you could consider a design where you avoid calling FreeRTOS APIs in global constructors. Perhaps, you could do part of the initialization once the code reaches app_main()?

[mmirad]

Thanks for your answers. Yes, or just avoid vTaskDelay() in the constructor. But my concern for asking this question was that there was something a bit more painful that was causing this. And I wasn't seeing it.

Well, I was also curious as to why it was working in version 4.3.

[mmirad]

Add some extra logs v5.3 (without vTaskDelay on ADC constructor, if not crash):
[0;32mI (1795) spi_flash: detected chip: generic
[0;32mI (1798) spi_flash: flash io: dio
ADC#1: CONSTRUCTOR
[0;32mI (1805) coexist: coex firmware version: dab85ae96
[0;32mI (1810) main_task: Started on CPU0
[0;32mI (1814) main_task: Calling app_main()

logs v4.3 (with vTaskDelay on ADC constructor):
[0;32mI (2237) spi_flash: detected chip: generic
[0;32mI (2240) spi_flash: flash io: dio
ADC#1: CONSTRUCTOR
[0;32mI (2247) cpu_start: Starting scheduler on PRO CPU.
[0;32mI (0) cpu_start: Starting scheduler on APP CPU.

[sudeep-mohanty]

Not using vTaskDelay() in the global constructor would be a solution. Since there isn't any change that we can make currently for this issue, I'll close it for now. In case you need more support, please feel free to re-open this ticket or open a new one for us. Thanks!