[BUG] RP2040, FreeRTOS SMP, CPU affinity and Timer ISR

[sdbbs]

Describe the bug
I have posted this on https://forums.freertos.org/t/rp2040-freertos-smp-and-timer-isr/15297 , however, as I have not had any responses, I suspect it might not be a trivial issue, and therefore possibly a bug.

Example RP2040 code has only a single task, and a timer ISR, is compiled against FreeRTOS SMP branch, and it is here: https://gist.github.com/sdbbs/b1410cd45106e0c0ee599f7fcdbb8f90/48e79e193537a9346682b014ffd50d34c940cc1b

Depending on how the timer ISR is initialized, and whether CPU core affinity is set for the task, there are four different behaviors I observe, and only one of them works as expected (behavior D):

(A)	//#define USE_HARDWARE_ALARM_API	vTaskCoreAffinitySet (xLedTaskHandle, 0b10);	led_task inits and stops, timer ISR runs for some ms, then stops
(B)	#define USE_HARDWARE_ALARM_API	vTaskCoreAffinitySet (xLedTaskHandle, 0b10);	led_task inits and stops, timer ISR runs continuously
(C)	#define USE_HARDWARE_ALARM_API	//vTaskCoreAffinitySet (xLedTaskHandle, 0b10);	led_task runs continuously, timer ISR never starts
(D)	//#define USE_HARDWARE_ALARM_API	//vTaskCoreAffinitySet (xLedTaskHandle, 0b10);	both led_task runs continuously, and timer ISR runs continuously

(I have also screenshots for these cases in the forum post)

I am puzzled as to why using vTaskCoreAffinitySet would cause tasks or timers to stop working.

Target

• Development board: Raspberry Pi Pico (RP2040)
• Instruction Set Architecture: Cortex M0+
• IDE and version: none
• Toolchain and version: MINGW64 arm-none-eabi-gcc.exe (GCC) 10.1.0

Host

• Host OS: Windows
• Version: Windows 10

To Reproduce

• Use project https://gist.github.com/sdbbs/b1410cd45106e0c0ee599f7fcdbb8f90/48e79e193537a9346682b014ffd50d34c940cc1b ; only other files that are required but not in the gist are the standard pico_sdk_import.cmake and FreeRTOS_Kernel_import.cmake
• Make changes as in the table, recompile, run on Raspberry Pi Pico, and observe the behaviors on the debug pins with an oscilloscope/logic analyzer

Expected behavior
I expected both the task and the timer ISR to run in parallel continuously, without stopping, regardless of which commands I use to set up the timer, or whether I use vTaskCoreAffinitySet to pin the task on CPU core 1.

Screenshots
Screenshots are available in the forum post

Additional context

[sdbbs]

Hi all,

Sorry about the panic, it turns out it might have been a "false alarm". Below a copy-paste of https://forums.freertos.org/t/rp2040-freertos-smp-and-timer-isr/15297/4 for reference, and I'm closing the issue:

Basically: the way I obtained the screenshots in the OP, was to first, run (in a MINGW64 bash terminal):

/c/path/to/openocd/src/openocd.exe -s /c/path/to/openocd/tcl -f interface/picoprobe.cfg -f target/rp2040.cfg -c "init ; reset halt ; exit"

... so I get everything to halt, and I get a bit of "empty space" at the left side of the screenshots; and then running:

/c/path/to/openocd/src/openocd.exe -s /c/path/to/openocd/tcl -f interface/picoprobe.cfg -f target/rp2040.cfg -c "init ; reset ; exit"

... to restart the code. Now, this openocd init/reset command has mostly been working fine for restarting code for me, ... until now.

---

Somewhat by accident, I discovered that, when I have an openocd running in one terminal, called via:

/c/path/to/openocd/src/openocd.exe -s /c/path/to/openocd/tcl -f interface/picoprobe.cfg -f target/rp2040.cfg

... and then I connect with gdb:

gdb-multiarch rp2040_fros_tmrisr_ex.elf -ex 'target extended-remote localhost:3333'

... and then I issue a run command, which also restarts the code:

(gdb) r
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: C:\path\to\rp2040_fros_tmrisr_ex\build\rp2040_fros_tmrisr_ex.elf

.... then, upon starting again, the code actually works fine, in the cases where we saw behaviors A and B previously !! (case for behavior D was already working, and it also keeps working in this case as well)

Strangely, behavior C persists, even when I re-run from gdb - so I guess the question of this thread can be reduced to that: why wouldn't the timer ISR start, if we use hardware_alarm_* commands, but do not use vTaskCoreAffinitySet to pin led_task to CPU core 1?

Regardless: what matters to me most, is that ultimately there is no problem with using vTaskCoreAffinitySet in FreeRTOS SMP with RP2040, regardless of which way I control the timer ISR, so it's nice to have confirmed that.

So, now I just have to find an openocd "one-liner" command, that can restart this type of code properly from the shell ...