This page needs a newer browser to run its tools. You can still read everything here.

MicroPython for Microcontrollers Module 5

Time, timers, interrupts and watchdogs interview questions

Interview questions on time, timers, interrupts and watchdogs: warm-ups, then what each harder question tests and how a good answer starts.

12 questions: 4 warm-ups and 8 with model answers · Levels: Fresher to staff

Warm-up questions

Short questions with short answers, each answered in full.

Fresher

What is the difference between time.ticks_ms() and time.time() on a microcontroller?

Answered in the lesson Time on a chip: ticks, sleeps and the RTC
Fresher

What is the difference between a soft and a hard timer callback in MicroPython?

Answered in the lesson machine.Timer: periodic and one-shot work
Fresher

Why can a hard interrupt handler in MicroPython not append to a list?

Answered in the lesson Interrupt handlers: hard IRQs, schedule and the heap
Fresher

Why should a watchdog be fed from the main loop and not from a timer callback?

Answered in the lesson Watchdogs, reset causes and safe recovery

Questions with model answers

What each question tests, the first step of a good answer and the follow-ups to expect.

Fresher to mid

Sensor boards in a greenhouse send a reading every minute. After 30 days the newest readings from the Pico boards are 26 minutes behind the server's clock, and every reading from the ESP32 boards appears about 30 years in the past. Explain both faults and how you would fix them.
What it tests

Telling drift from a sleeping loop apart from an epoch mismatch, working out the error per reading from the totals, and sending timestamps that do not depend on the board's port.

First step

Turn the totals into an error per reading: 26 minutes over 30 days of minute readings is 1,560 s over 43,200 readings, about 36 ms each, which is what one reading's work takes, so the loop sleeps a full minute after its work. The 30 years is 946,684,800 s: the esp32 port counts from the start of 2000.
Follow-ups
- Why do the Pico boards not show the 30-year error?
- How do you keep readings on the minute after a Wi-Fi reconnect that takes 20 seconds?
- What should each reading carry so that the server never depends on a board's epoch?
From the lesson Time on a chip: ticks, sleeps and the RTC
Model answer, Pro. Model answers open with any pass; prices are in the notice on this page.
Opening the model answers with your pass…
Model answers open with any MySmartCoPilot pass.
Pro pass · 1 week₹79$2.99
30 days₹179$5.99
1 year₹1,699$45
One payment; a pass never renews. The price shown is the total you pay: no fees or charges are added at checkout.
Passes can’t be bought right now, so the model answers can’t be opened at the moment. If you have a pass, enter your licence key.
Choose a pass I have a licence key
It also opens every other in-depth part in Learn and every Pro tool. Sales are final, except where the law gives you a right to withdraw, for example in the EU and the UK (refund policy).
In the answer:
- Model answer
- Follow-up answers
- Common mistakes
- Rubric
- Variants
- about 4 minutes
Mid to senior

A Pico W opens an irrigation valve at 06:00 India time every day. Design how the board knows the time, from power-up to the daily trigger, and say what it does when the network is down or the clock has just been corrected.
What it tests

The RTC's start value, setting it from NTP, keeping UTC inside and converting the local schedule once, and how a schedule behaves while the clock is unset or when it jumps.

First step

Separate the two clocks. The RTC gives the date but starts at the beginning of 2021 after every power-up or hard reset, so the board must not trust it until ntptime.settime() has succeeded. Keep everything in UTC: 06:00 IST is 00:30 UTC, so the trigger is the first moment of each UTC day at or after 00:30.
Follow-ups
- What does the board do after a power cut at 05:50 while Wi-Fi is down?
- How do you stop the valve opening twice when NTP moves the clock back by a few seconds?
- How would you test the daily trigger without waiting a day?
From the lesson Time on a chip: ticks, sleeps and the RTC
Model answer, Pro.
In the answer:
- Model answer
- Follow-up answers
- Common mistakes
- Rubric
- Variants
- about 3 minutes
Mid to senior

A Pico samples a vibration sensor at 1 kHz from a soft machine.Timer callback, and the main program appends the samples to a log file. Every time the log is written to flash, about 10 ms of samples go missing, and no error is printed. Explain why, and redesign the sampling so that no sample is lost.
What it tests

How soft callbacks are queued and dropped, why a flash write on a Pico holds back hard callbacks as well, and keeping flash writes out of the sampling path.

First step

Count what the queue can hold. On a Pico a flash write runs with interrupts off, so the timer's expiries wait and are dispatched together when it ends, and the rp2 port queues at most 8 soft callbacks. A write of 18 ms at 1 kHz queues 8 samples and drops the other 10 without a word, because soft dispatch ignores a full queue.
Follow-ups
- Why is nothing printed when samples are dropped?
- Why does hard=True not save the samples on a Pico?
- How do you show on the bench that no sample is lost any more?
From the lesson machine.Timer: periodic and one-shot work
Model answer, Pro.
In the answer:
- Model answer
- Follow-up answers
- Common mistakes
- Rubric
- Variants
- about 4 minutes
Fresher to mid

A status LED on a Pico is blinked by a periodic machine.Timer that a setup() function creates. In the field it stops blinking at a different moment each time, minutes or hours after start-up, and no error is printed. What is happening, how do you fix it, and how would you show that the fix works?
What it tests

Object lifetime and the garbage collector, the rp2 Timer's finaliser, how the esp32 port differs, and turning a random-looking fault into a test that fails every time.

First step

Ask what refers to the timer once setup() has returned: nothing. On the rp2 port a Timer is an ordinary heap object with a finaliser, so the next garbage collection frees it and stops it. Collections run when an allocation finds no room, so the moment depends on everything else the program allocates.
Follow-ups
- Why does the same code keep blinking on an ESP32?
- How do you make the failure happen at once in a test?
- Which other objects stop working when the collector frees them?
From the lesson machine.Timer: periodic and one-shot work
Model answer, Pro.
In the answer:
- Model answer
- Follow-up answers
- Common mistakes
- Rubric
- Variants
- about 3 minutes
Mid to senior

A Pico counts flow-meter pulses with a hard pin handler that does counts[hour] += 1 on a dict of hourly counts. In the field the count stops rising a few hours after start-up while water still flows, and the console showed one error. What happened, and how do you rebuild the handler?
What it tests

Which constructs need the heap, why a new dict key fails in a hard handler, what a failing handler leaves behind, and moving the bookkeeping into the main loop.

First step

Find what changed hours after start-up: the hour. The first pulse of a new hour inserts a new key into the dict, which may need a bigger table, and the heap is locked in a hard handler. The MemoryError switched the handler off, so every later pulse is ignored.
Follow-ups
- Why did it pass every test on the bench?
- What would make a handler that only adds 1 fail after about 12 days instead?
- How do you prove that the new handler creates no objects?
From the lesson Interrupt handlers: hard IRQs, schedule and the heap
Model answer, Pro.
In the answer:
- Model answer
- Follow-up answers
- Common mistakes
- Rubric
- Variants
- about 3 minutes
Mid to senior

A motor's encoder raises a hard pin interrupt up to 2,000 times a second on a Pico W, and the main loop publishes the speed over MQTT once a second. Design the hand-off between the handler and the main loop so that no count is lost, and say how you would test it.
What it tests

Choosing between a counter in a critical section and a ring buffer, sizing from the rates, the limits of schedule(), and testing races with interleavings and long blocking calls.

First step

Work out what must cross the boundary. The main loop needs only how many edges came in the last second, not when each came, so one small-integer counter is enough: the handler adds 1, and once a second the main loop copies and resets it inside a two-line critical section. 2,000 a second never comes near 2**30.
Follow-ups
- Why not call schedule() on every edge?
- When would you switch to a ring buffer of timestamps?
- How do you test that no count is lost while an MQTT publish blocks for a second?
From the lesson Interrupt handlers: hard IRQs, schedule and the heap
Model answer, Pro.
In the answer:
- Model answer
- Follow-up answers
- Common mistakes
- Rubric
- Variants
- about 3 minutes
Mid to senior

After an update, Pico W boards in the field restart about every 40 seconds. machine.reset_cause() logs WDT_RESET each time, but the code has no loop that could hang. How do you work out what is happening, and what do you change so that the next fault like this is easy to diagnose?
What it tests

Knowing that on rp2 WDT_RESET also covers machine.reset() and deep-sleep wakes, leaving notes in backup memory before planned resets, and logging enough to tell a hang from a planned restart.

First step

Do not take WDT_RESET at its word on a Pico: machine.reset() and a wake from deepsleep() report it too. Search the update for every machine.reset() and deepsleep() call, such as an error handler that restarts the board, before looking for a hang.
Follow-ups
- How would you tell a real watchdog reset from your own machine.reset() in the field?
- The watchdog really is firing. How do you find the step that hangs?
- Why would the restarts come every 40 seconds and not every 5?
From the lesson Watchdogs, reset causes and safe recovery
Model answer, Pro.
In the answer:
- Model answer
- Follow-up answers
- Common mistakes
- Rubric
- Variants
- about 3 minutes
Senior to staff

Design the start-up and recovery of an ESP32 pump controller on a remote farm, reachable only over Wi-Fi. It must never leave the pump running when its app hangs, must not drain its solar battery in a boot loop, and must stay reachable for a fix. Walk through what main.py does at each boot.
What it tests

Combining a watchdog fed after health checks, reset causes, a crash count in backup memory, back-off and a safe mode that keeps the update path, with the pump's safe state first.

First step

Put the pump's safe state first: the first lines of main.py switch the pump off, before anything can fail. Then read machine.reset_cause() and the crash count in machine.mem_backup(), trusted only behind a magic number, and decide: start the app now, after a back-off wait, or not at all.
Follow-ups
- What timeout do you choose, and what feeds the watchdog?
- How does a fix reach a board that is in safe mode?
- What resets the crash count, and when?
From the lesson Watchdogs, reset causes and safe recovery
Model answer, Pro.
In the answer:
- Model answer
- Follow-up answers
- Common mistakes
- Rubric
- Variants
- about 3 minutes

The lessons of this module

Time on a chip: ticks, sleeps and the RTC Free lesson, Pro answers: 25 minutes
machine.Timer: periodic and one-shot work Free lesson, Pro answers: 20 minutes
Interrupt handlers: hard IRQs, schedule and the heap Free lesson, Pro answers: 20 minutes
Watchdogs, reset causes and safe recovery Free lesson, Pro answers: 20 minutes

All MicroPython for Microcontrollers interview questions · The MicroPython for Microcontrollers track

Warm-up questions

What is the difference between time.ticks_ms() and time.time() on a microcontroller?

What is the difference between a soft and a hard timer callback in MicroPython?

Why can a hard interrupt handler in MicroPython not append to a list?

Why should a watchdog be fed from the main loop and not from a timer callback?

Questions with model answers

Sensor boards in a greenhouse send a reading every minute. After 30 days the newest readings from the Pico boards are 26 minutes behind the server's clock, and every reading from the ESP32 boards appears about 30 years in the past. Explain both faults and how you would fix them.

A Pico W opens an irrigation valve at 06:00 India time every day. Design how the board knows the time, from power-up to the daily trigger, and say what it does when the network is down or the clock has just been corrected.

A status LED on a Pico is blinked by a periodic machine.Timer that a setup() function creates. In the field it stops blinking at a different moment each time, minutes or hours after start-up, and no error is printed. What is happening, how do you fix it, and how would you show that the fix works?

A Pico counts flow-meter pulses with a hard pin handler that does counts[hour] += 1 on a dict of hourly counts. In the field the count stops rising a few hours after start-up while water still flows, and the console showed one error. What happened, and how do you rebuild the handler?

A motor's encoder raises a hard pin interrupt up to 2,000 times a second on a Pico W, and the main loop publishes the speed over MQTT once a second. Design the hand-off between the handler and the main loop so that no count is lost, and say how you would test it.

After an update, Pico W boards in the field restart about every 40 seconds. machine.reset_cause() logs WDT_RESET each time, but the code has no loop that could hang. How do you work out what is happening, and what do you change so that the next fault like this is easy to diagnose?

Design the start-up and recovery of an ESP32 pump controller on a remote farm, reachable only over Wi-Fi. It must never leave the pump running when its app hangs, must not drain its solar battery in a boot loop, and must stay reachable for a fix. Walk through what main.py does at each boot.