ISR and saving to a file, ESP32 versus STM32F411

[davefes]

For several years I have been doing this on the ESP32 to catch watchdog timeouts:

def wdt_callback():
    global _wdt_counter
    global _wdt_timeout
    
    if (_wdt_counter >= _wdt_timeout):
        try:
            with open('errors.txt', 'a') as outfile:
                outfile.write('had a wdt event' + '\n')
        except OSError:
            pass

        print('doing a machine.reset()')
        time.sleep_ms(10)
        machine.reset()

Trying to the same on an STM32F411 throws up the error:
uncaught exception in Timer(1) interrupt handler

If I remove the try/except, saving to a file, the error disappears. Reading some old threads it seems that using a print statement is problematic, but seems OK in this case.

Have I tripped-over a difference in the way ISRs behave on the two platforms?

[robert-hh]

There is a difference between hard and soft interrupts. Soft interrupts schedule the handler as a normal Python function. It can use the all Python functions and especially allocate memory. Hard interrupts are called by the MCU interrupt handler directly. They can use only a limited set of Python features and especially they must not allocate memory, and they cannot handle exceptions. So I assume that in your case you use a hard interrupt handler for you Timer functions. See also https://docs.micropython.org/en/latest/reference/isr_rules.html

I doubt that you really use a hardware watchdog, because than the usual response would be a hard reset,

[davefes]

Correct, no hardware watchdog.

For the ESP32:

    wdt_timer = machine.Timer(3)  # hardware timer for ESP32
    wdt_timer.init(period=1000, mode=machine.Timer.PERIODIC, callback=lambda t: wdt_callback())

and for the STM32F411:

    wdt_timer = pyb.Timer(1, freq=1, callback=lambda t: wdt_callback())

I have read that doc and searching it again, hard is mentioned several times and soft once.

Ah, a search for micropython esp32 timer soft hard turns this up:

Some key things to be aware of:
- MicroPython has both "bare-metal" (e.g. STM32) and "OS" (e.g. ESP32, Linux) ports. On the bare metal ports, when a hardware interrupt fires, the Python VM is executed in the context of the hardware interrupt (i.e. no delay). Hardware interrupts are not blocked by the garbage collector, and hard interrupt handlers may not allocate.
- On OS ports, interrupts happen in "scheduler" context which may have a delay as the VM only runs the scheduler every N instructions, and the VM is blocked while the GC is running.

Thanks for the hints.

[davefes]

Now I read that the ESP32 uses soft timers, is the comment wdt_timer = machine.Timer(3) # hardware timer for ESP32 incorrect?

Maybe saying # hardware timer for ESP32 using soft interrupts is better?

[rkompass]

You may convert the hard interrupt into a soft interrupt by using micropython.schedule().
This way in the ISR function you do not call the wdt_callback() directly but indirectly.
BUT
a wdt_timer = pyb.Timer(1, freq=1, callback=lambda t: schedule(wdt_callback, (,)) won't work, because it allocates a reference to wdt_callback(), at least according to the docs. (Maybe this was my problem with the Lora last year .??).
Instead you need to create a class, where the reference to the wdt_callback is already created beforehand, e.g. in the class constructor.
See the example in the docs (class Foo(): ), which you may use with minimal changes.

[davefes]

@rkompass, thank you for the added info. Using micropython.schedule could be my next challenge :)