[BUG] RP2350 ARM_NTZ port: pre-scheduler `taskEXIT_CRITICAL` leaves `BASEPRI` raised

[romain145]

Describe the bug
On the RP2350 ARM_NTZ port, any FreeRTOS API that uses taskENTER_CRITICAL / taskEXIT_CRITICAL before vTaskStartScheduler() leaves BASEPRI set to configMAX_SYSCALL_INTERRUPT_PRIORITY instead of restoring its previous value (0). This silently masks all interrupts at or below that priority for the remainder of the pre-scheduler init phase.

Target

• Development board: Raspberry Pi Pico 2 (RP2350)
• Instruction Set Architecture: ARMv8-M (Cortex-M33, non-TrustZone)
• Port: portable/ThirdParty/GCC/RP2350_ARM_NTZ
• Kernel version: V11.3.0
• SDK: pico-sdk 2.2.0
• Toolchain: arm-none-eabi-gcc

Host

• Host OS: Windows

To Reproduce
In main(), before vTaskStartScheduler(), call any FreeRTOS create API and read BASEPRI before and after:

static inline uint32_t read_basepri(void) {
    uint32_t v; __asm volatile ("mrs %0, basepri" : "=r" (v));
    return v;
}

int main(void) {
    stdio_init_all();

    uint32_t bp_pre = read_basepri();              // 0x00

    static StaticSemaphore_t buf;
    SemaphoreHandle_t m = xSemaphoreCreateMutexStatic(&buf);

    uint32_t bp_post = read_basepri();             // 0x10
}

Observed: bp_pre = 0x00, bp_post = 0x10 (= configMAX_SYSCALL_INTERRUPT_PRIORITY). The same occurs with xQueueCreate, xSemaphoreCreateBinary, and any other API that internally enters a critical section.

The practical consequence in my project: pico_stdio_usb output hangs during init because USBCTRL_IRQ (priority 0x40) is masked, TinyUSB never sees transfer-complete events, and the CDC TX FIFO never drains. printf blocks until PICO_STDIO_USB_STDOUT_TIMEOUT_US expires and silently drops bytes.

Expected behavior
After a taskENTER_CRITICAL / taskEXIT_CRITICAL pair called before the scheduler is running, BASEPRI should be restored to its previous value (0), not set to configMAX_SYSCALL_INTERRUPT_PRIORITY.

Additional context

Relevant config:

• configMAX_SYSCALL_INTERRUPT_PRIORITY = 16
• configSUPPORT_STATIC_ALLOCATION = 1
• configSUPPORT_PICO_SYNC_INTEROP = 1
• configNUMBER_OF_CORES = 2 (SMP)
• configRUN_FREERTOS_SECURE_ONLY = 1

Workaround: save and restore BASEPRI manually around pre-scheduler FreeRTOS calls, or defer all FreeRTOS object creation to a task that runs after vTaskStartScheduler().

[richard-damon]

I believe the behavior is intentional, so not a bug. It is expected that interrupts below configMAX_SYSCALL_INTERRUPT_PRIORITY might use FreeRTOS APIs, which is not allowed before the scheduler is started. Normally you limit what is done before starting the scheduler to the base minimum needed to setup your system to run with the scheduler enabled.

[romain145]

Thanks for the quick response. I'd like to add 2 comments:

• The behavior is asymmetric. BASEPRI is 0 on entry to xSemaphoreCreateMutexStatic and 0x10 on exit - the critical section raises the mask but never lowers it. A symmetric implementation would save and restore BASEPRI, exactly as the post-scheduler path does.

• It masks unrelated interrupts. The interrupt broken in my case is USBCTRL_IRQ, used by pico_stdio_usb. Its handler contains no FreeRTOS calls. The *Static create APIs are explicitly designed to be callable early, so it's reasonable to expect that calling one doesn't silently disable unrelated interrupts for the rest of init, at a minimum this should be documented.

If the current behavior is genuinely intentional, could you advise on the recommended pattern for application init under FreeRTOS?

• Should all FreeRTOS object creation (mutexes, queues, semaphores) be deferred to a startup task that runs after vTaskStartScheduler(), rather than being created in main() before the scheduler starts?
• Is the intended pre-scheduler phase limited strictly to hardware/clock setup, with everything else (including driver init that needs Mutexes) moved into a startup task?

I have a workaround either way; I'd just like to follow the intended idiom for future projects. Thanks!

[richard-damon]

No, the problem is that your environment doesn't meet the FreeRTOS base expectations. Processors start with interrupts disabled, and FreeRTOS assumes this is the status when you start to setup the system. The problem you are running into is that you actually have two different "Operating Systems" (The Raspberry Pi Pico support, and FreeRTOS) running at the same time, and the Pi Pico support isn't fully FreeRTOS compatible. FreeRTOS is designed for a wide variety of processors, and lays out its expectations (like interupts are not expected to be used pre-scheduler). If the RP Pico support package wants to add FreeRTOS to its capabilities, it is ITS responsibility to handle the compatibility issues.

As to "unrelated" interrupts, if you want an interrupt to really be considered "unrelated" to FreeRTOS, it needs to have a priority "higher" than configMAX_SYSCALL_INTERRUPT_PRIOIRITY. In normal cases, a USB driver SHOULD be using FreeRTOS primatives to handle the processing, the fact that the support library doesn't means it must be introducing "polling" loop into the program, breaking the fundamental principles of real-time operation. This is the reality of "not quite compatible" packages like this using FreeRTOS, they are using it as a cheap threading support, but break a lot of the real-time capabilities.

As to the expectation, FreeRTOS objects needed for the system should be created before calling vTaskStartScheduler(), and no code needing interrupts should be in use during that time. This can involve a lot of "driver setup", as most of that doesn't need interrupts. Device setup that needs interrupts should happen in the period right after starting the scheduler, typically in the begining code of the task that handles that device. Since pre-scheduler the system is running single processor, there is no need for Mutexes at this point. Perhaps your issue is that "stdio_init_all()" should be delayed until the scheduler starts, as with any code that wants to access that stdio. There is a hook describe at https://freertos.org/Documentation/02-Kernel/02-Kernel-features/12-Hook-functions#daemon-task-startup-hook that if the Timer Task is setup as the highest priority task will be the first thing that happens after the scheduler starts, though since your system is SMP, you may need to signal other tasks that want to use the library when that initialization is complete.