Timer callback gets stuck when thread is running - RP2040

[EliAaron]

There seems to be a problem using the Timer and a thread simultaneously. The timer randomly gets stuck after a few seconds. The higher the frequency of the timer, the quicker it gets stuck.

Note: I am using MicroPython v1.19.1 where rp2 memory corruption bug in thread was fixed.

I came across these two links which seem to be about the same issue, with no solution:
Timer callback stops with uart thread
Problem with machine.Timer() and _thread on Raspberry Pi Pico (RP2040)

I posted a question on the MicroPython forum:
Timer gets stuck when thread is running - RP2040.

Reproducible example

I wrote a simple example that demonstrates the problem and is easy to reproduce with any Pico board.

In the example, the Pico LED is toggled in a thread and a timer runs with a callback that prints an incrementing counter.

import time
import _thread
from machine import Pin, Timer

led = Pin(25, Pin.OUT)
counter = 0

def blink_func():
    led.toggle()

def print_func():
    global counter
    print(f"counter = {counter}")
    counter += 1
        
def thread_loop(freq, func):
    delay = 1/freq
    while True:
        func()
        time.sleep(delay)

def start_timer(freq, func):
    tim = Timer()
    tim.init(freq=freq, mode=Timer.PERIODIC, callback=lambda t:func())
    
def start_thread(freq, func):
    _thread.start_new_thread(thread_loop, (freq, func))


start_timer(3000, print_func)
start_thread(50, blink_func)

# This avoids an error from Thonny that probably has to do with the REPL and the printing
try:
    while True:
        pass
finally:
    pass

The problem may be about interrupts and threads

I suspect the core of the problem is not specific to timers and threads, it is about interrupts and threads.

The reason I write this is because I encountered a similar problem In two other cases:

1. Non blocking writes with I2S on a second thread: I wrote a WAV player that uses the I2S object. the streaming of the output was does on a second thread. I tried to speedup the streaming by using none blocking writes:

   audio_out.irq(i2s_callback)         # i2s_callback is called when buf is emptied
   num_written = audio_out.write(buf)  # returns immediately

   When I did not use a thread, it worked fine. When I did use a second thread, it would get stuck after a few seconds.

2. Input pin interrupts when second thread is running: I configured pins with interrupt handlers

   Pin.irq(...)

   When I had a thread running in the background (streaming WAV with I2S), the callbacks would randomly strop getting triggered after a few seconds. The more frequent the irq calls, the faster it would get stuck.
   I tried using:

   Pin.irq(..., hard=False)

   and

   Pin.irq(..., hard=True)

   There was some difference (I don't remember) but the irq always would stop getting triggered after a few seconds.

   A simple example can be written to check the problem with pin interrupts and threads but I am currently working on a different project...

[rkompass]

I will try you program later. Seeing start_timer(3000, print_func) with print_func accessing a global counter and printing I guess that 330 us (1/3000 Hz) is just not enough time. So print() might get stuck in an ever longer attempt to store the strings to be printed. If you could just count and check the variable increase from outside...
I suggest to time print_func, so you can determine the limit frequency from this (after adding a reasonable delay for the interrupt itself, say 15-50 us).

[rkompass]

Now I have timed print_func(): It takes 545 us. This suggests that an interrupt frequency above 1750 Hz (= 570 us Period) is problematic.
I suggest you use something like

def count_func():
    global counter
    counter += 1

instead, which takes only about 19 us (on my RPi2, with standard 125MHz).
In a global while loop with some sleep you might print the counter increases and compute how many per second it were in each interval, and this way check when the interrupts begin to slow down.

If you want to get nearer to the limit you may decorate a counter function with @micropython.viper:

gv32 = b'\x00\x00\x00\x00'

@micropython.viper
def incr_gv32():
    global gv32
    ptr32(gv32)[0] += 1
    
incr_gv32()
print(f'End value of gv32: {int.from_bytes(gv32, 'little')}')

This reduces the average time of increasing the counter to below 8 us. So perhaps you may get into the range of tens of kHz with the timer interrupt.

My conclusion so far is: The reproducible example seems problematic for reasons unrelated to threads or interrupts.

This of course does not imply that the problems you describe do not exist.
I cannot tell anything regarding I2S, as I didn't use it so far.
As for

2. Input pin interrupts when second thread is running:

I suggest you present example code also for this case.
If you used printing there too, perhaps your problems go away if you avoid trying to print in rapid succession (in each interrupt).

[EliAaron]

As far as I can remember, I encountered the problems with infrequent printing and without printing at all. I actually gave up on using interrupts while multithreading.

I am not sure I can find the time to test this again, I am currently working on a different project. I posted this problem on the MicroPython forum but no solution there. I thought it was important to bring up this problem, I am not the only one who has encountered it, so I posted it now (a little to late...) before I move on too far from my MicroPython project.

[rkompass]

I changed your program to eliminate the printing from the timer callback:

from time import sleep_ms, ticks_us, ticks_diff
import _thread
from machine import Pin, Timer

led = Pin(8, Pin.OUT)
counter = 0

def blink_func():
    led.toggle()

def count_func(timer):
    global counter
    counter += 1
        
def thread_loop(freq, func, func2):
    delay = round(1000/freq)
    while True:
        func()
        func2(delay)

def start_timer(freq):
    tim = Timer()
    tim.init(freq=freq, mode=Timer.PERIODIC, callback=count_func)
    
def start_thread(freq, func):
    _thread.start_new_thread(thread_loop, (freq, func, sleep_ms))


start_timer(30000)
# start_thread(40, blink_func)

t0 = ticks_us()
c0 = counter
while True:
    sleep_ms(999)
    t1 = ticks_us(); c1 = counter
    tics_per_us = (c1-c0) / ticks_diff(t1,t0)
    t0 = t1; c0 = c1
    print(1000000*tics_per_us)

and can confirm that there is a problem. Without start_thread(40, blink_func) there is a limit of about 30 kHz for the timer callback (33us --> 19us for counting function, estimate 14us for scheduling - finding a gap within executing byte code?).
With start_thread(40, blink_func) it degrades to about 3 kHz (330us).

After following the references I see that you posted your example program before on the forum (with the timing-of-print() issue).
I hope that @jimmo has this still on his long long todo-list :-)