Program freezes on startup if I include "FreeRTOS.h"

[ruifig]

I'm experimenting with adding FreeRTOS tasks.
With a minimal application it works fine but with my actual project, it's freezing at startup with this callstack:

sleep_until@0x1003774a (\sleep_until.dbgasm:43)
capture_additional_rosc_samples@0x10045778 (Unknown Source:151)
initialise_rand@0x10045822 (Unknown Source:210)
get_rand_64@0x10045822 (\get_rand_64.dbgasm:66)
get_rand_32@0x100459c2 (\get_rand_32.dbgasm:3)
udp_init@0x10042196 (\udp_init.dbgasm:3)
lwip_init@0x1004794c (\lwip_init.dbgasm:7)
lwip_nosys_init@0x10045550 (\lwip_nosys_init.dbgasm:8)
cyw43_arch_init@0x1003d088 (\cyw43_arch_init.dbgasm:14)
cyw43_arch_init_with_country@0x1003ce82 (\cyw43_arch_init_with_country.dbgasm:5)
initVariant@0x100035cc (c:\Users\Rui\.platformio\packages\framework-arduinopico\variants\rpipicow\picow_init.cpp:65)
main@0x10034326 (c:\Users\Rui\.platformio\packages\framework-arduinopico\cores\rp2040\main.cpp:99)

Still investigating to see if I can pinpoint why it works with one and fails with another, but any tips are welcome if this rings any bells. :)

The only thing that crosses my mind is that maybe I have some global objects with non-trivial constructors that somehow messes things up before main is called, but don't think that's the case.

For context, what I'm trying to do is to make use of the rp2040 watchdog in my application, which works fine using Arduino-Pico's rp2040 object.
But as far I've noticed, there is no way to disable the watchdog once enabled, so if we call into any third-party code or Arduino-Pico's code that takes too long to complete, like for example connecting to Wifi, then there a good chance it will trigger a watchdog reboot.

The workaround I'm trying is to create a very simple FreeRTOS task that allows me to implement a watchdog pause of sorts.
For example, I created a task like this (stays suspended)

void autoResetTask(void* pvParameters)
{
	while(true)
	{
		rp2040.wdt_reset();
		delay(250);
	}
}

Under normal circumstances, my application calls rp2040.wtd_reset() periodically, then when I know I'm calling code that potentially can take longer than 8300ms, I wrap that code with a vTaskResume / vTasSuspend to enable/disable the watchdog auto reset.
This is all working fine with a minimal(ish) sample application I was playing around with, but with my actual application if freezes at startup as explained above.
I know this won't work with cooperative multitasking (I think Arduino-Pico's FreeRTOS uses cooperative, right?), but I'm not too bothered, since Wifi code does a few delays when connecting.

[earlephilhower]

Can you grab both cores' stacks to see where everything is at?

The FreeRTOS here is SMP (and it is pre-emptive) and the Pico-SDK 1.5 added a new random generator module. I would guess that it's not compatible with either multiple cores or multi-threads on the same core calling it. The task switching in SMP FreeRTOS used the PendSV exception and is pretty heavy handed. Extreme blocking was required to get any flash accesses going (since both cores not only need to be stopped in RAM loops, the PendSV exception...which is not maskable...needs to not switch out the tasks on either core).

FWIW, you will need to make sure only core0 is used to access any WiFi-related calls. That's a function of the hardware/SDK (the SDK assumes Core0 AIUI, and even if it didn't then the necessary IRQs/mutexes/etc. would not work if you tried doing anything related to WiFi on the other core).

Re: the WDT task you're running, I'm not so sure it's really a good idea to ping the WDT in a while loop. In most critical systems I've seen, the WDT is only reset when forward progress is made "doing something." In this, case, for example you could end up in an infinite loop elsewhere and the algorithm stuck, but the WDT would not catch it or reset the chip...

[ruifig]

Seems like the other core is not doing anything yet:

Also, figured out why the sample application worked and my real application didn't.

extern "C" void initVariant() {
    __isPicoW = CheckPicoW();
    if (__isPicoW) {
        cyw43_arch_init_with_country(WIFICC);
    }
}

The sample application was setup to use a Pico while my real application uses a PicoW.
Once I change the sample application to use a PicoW, it also freezes.

Regarding pinging the WDT in a while loop in a separate task, that's just a workaround to avoid the WTD triggering while calling code that takes too long and I can't or don't want to change, like connecting to WiFi.
For example, calling WifiMulti::run can take longer than 8300ms, triggering the WTD.

So, back to the freeze, seems like the easiest way to repro this is to simply create a minimal application for PicoW and include the FreeRTOS.h header. It has nothing to do with using the WTD. That was just a coincidence.
This is enough to repro:

#include <Arduino.h>
#include <FreeRTOS.h> // << Just including this causes the freeze

void setup()
{
	Serial.begin(115200);
	Serial.println("Hello world");
}

void loop()
{
	Serial.println(millis());
	delay(1000);
}

My platformio.ini

[platformio]
default_envs = earlephilhower

;
; Custom data group
; can be use in [env:***] via ${common.***}
[common]
picoprobe_tools_path = B:/Utils/Picoprobe

[env:earlephilhower]
platform = https://github.com/maxgerhardt/platform-raspberrypi#5a533d6b36844183bb72794bc53091206165e921
board = rpipicow
framework = arduino
board_build.core = earlephilhower
build_type = debug
upload_protocol = custom
upload_command = ${common.picoprobe_tools_path}/upload_openocd.bat "$BUILD_DIR/${PROGNAME}.elf" "$PROJECT_DIR"
debug_tool = custom
debug_server = 
	${common.picoprobe_tools_path}/debug_openocd.bat
debug_port = localhost:3333
lib_ldf_mode=chain+