A single FreeRTOS task does not start - debugging suggestions?

[sdbbs]

Hi all,

Many thanks for the response, @richard-damon - it seems I finally got further, so I’d like to document this.

@richard-damon

As for the deadlock, I am having a bit of trouble following all you are doing,

Indeed - so let me try to summarize:

First post (OP) was me asking a generic question, which opened up and clarified some misunderstandings that I’ve had - but there was no definite answer on the “single task does not start” problem.

So then, I came up with a “minimal example” that tried to emulate the original problem, which is in the gist; it has a timer ISR that generates random data; a led_task which starts the timer ISR, but is otherwise independent; the timer ISR pushes data to working_task_01 via a queue; and depending on the data, working_01_task wakes either working_02_task or working_03_task. To demonstrate my proprietary problem, I would have had to have one more task - but the problem was, that even without it, the described setup would start, and after some milliseconds, the program would stop running (as visible from the “oscilloscope” capture of the GPIO pins).

So, what is “solved” now is this gist example; as deduced in RP2040, FreeRTOS SMP and Timer ISR , it turns out that the problem was not in the code itself, but in the way the code is restarted via “reset” of the MCU: what works is that either you connect with gdb over openocd to the MCU, and issue gdb run to restart the code - or, if using just openocd to restart the MCU, one must make sure that core 1 is started before core 0:

/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 ; rp2040.core1 arp_reset assert 0 ; rp2040.core0 arp_reset assert 0 ; exit"

I don’t understand why core 1 needs to be started first, but it seems to work; for instance, here is the “oscilloscope” trace of the GPIO pins of the program from post #11, for the last gist revision ( ee51b8 ):

Note the timing axis - this screenshot means that the tasks started running continuously, and there is no “stop” after some 90 ms; which from my perspective, means that the code is working.

Again, there was no change in the code from gist rev. ee51b8 to obtain working behavior - I just used the one-liner openocd command for reset that starts core 1 before core 0 (instead of the classic init ; reset ; exit).

So, I will mark this post as a solution, but it is a solution to post #11; the OP cannot really be answered, as I’ve had too many understandings when I was writing that question. If I ever come to the similar problem, I’ll make a new example, and post a new question.

@richard-damon

but using a spin-lock in an ISR is a bit dangerous, as it effectively reduces the number of CPUs available to resolve the spinlock by one (as that CPU will never switch to a task to resolve the issue) so if all CPUs get into such a spinlock, you are deadlocked, that says that in the SMP version of FreeRTOS, using things based on spinlocks in an ISR are not really safe unless care is taken to avoid that problem.

At first, my initial response to this was “but, I am not using a spinlock in an ISR anywhere?! Backtrace shows it stems from isr_pendsv → vTaskSwitchContext → vPortRecursiveLock”; but upon later reading, I did notice " in the SMP version of FreeRTOS"…

In any case, it seems that was not the problem with the deadlock - again, it seems that one simply needs to ensure that core 1 is started before core 0 when restarting the code (by resetting the chip)… although I’m not 100% sure myself, as I haven’t had any confirmation about that from others - simply my observations of how the code behaves.

@richard-damon

Flushing a queue is one of the valid cases of using a 0 timeout, if something is in the queue you get it, and you can get another, until you get a 0 then the queue is empty. But, if you never want more than one item in the queue, just make the queue length 1, and you can’t overfill it. (And you can then use xQueueOverwrite[FromISR] to put the item on it to make it always the most recent).

Thanks, that’s a great tip!

And thanks again, all, for the assistance!