Watchdog reset recovery in Embedded C - Time & Space Complexity
We want to understand how the time taken by watchdog reset recovery code changes as the system runs.
Specifically, how the recovery steps affect the program's running time.
Analyze the time complexity of the following code snippet.
void watchdog_reset_recovery(void) {
if (is_watchdog_reset()) {
clear_watchdog_flag();
for (int i = 0; i < RECOVERY_STEPS; i++) {
perform_recovery_step(i);
}
}
}
This code checks if a watchdog reset happened, clears the flag, and performs a fixed number of recovery steps.
Identify the loops, recursion, array traversals that repeat.
- Primary operation: The for-loop running recovery steps.
- How many times: Exactly RECOVERY_STEPS times, which is a fixed number.
The number of recovery steps does not change with input size; it stays the same.
| Input Size (n) | Approx. Operations |
|---|---|
| 10 | RECOVERY_STEPS times |
| 100 | RECOVERY_STEPS times |
| 1000 | RECOVERY_STEPS times |
Pattern observation: The work done does not grow with input size; it stays constant.
Time Complexity: O(1)
This means the recovery code takes the same amount of time no matter how big the input or system state is.
[X] Wrong: "The recovery loop time grows with the size of the program or input data."
[OK] Correct: The recovery steps count is fixed and does not depend on input size, so the time stays constant.
Understanding fixed-time recovery routines helps you explain how embedded systems handle errors efficiently without slowing down as data grows.
"What if the recovery steps depended on the size of a data buffer? How would the time complexity change?"
Practice
What is the main purpose of checking the watchdog reset flag at system startup?
Solution
Step 1: Understand watchdog reset flag role
The watchdog reset flag indicates if the last reset was caused by the watchdog timer expiring.Step 2: Purpose of checking the flag at startup
Checking this flag helps the program know if it needs to perform recovery actions after an unexpected reset.Final Answer:
To detect if the system was restarted due to a watchdog timeout -> Option CQuick Check:
Watchdog reset flag = detect watchdog reset [OK]
- Thinking the flag disables the watchdog
- Assuming it resets variables automatically
- Confusing flag with timer interval setting
Which of the following code snippets correctly clears the watchdog reset flag in embedded C?
/* Assume WDT_RESET_FLAG is the flag variable */
// Clear the flag
?Solution
Step 1: Identify correct syntax to clear a flag
In embedded C, clearing a flag usually means setting its variable to zero.Step 2: Analyze each option
WDT_RESET_FLAG = 0; sets the flag to 0, which clears it. clear(WDT_RESET_FLAG); uses a non-standard function. WDT_RESET_FLAG == 0; uses comparison, not assignment. reset_flag(WDT_RESET_FLAG); uses an undefined function.Final Answer:
WDT_RESET_FLAG = 0; -> Option AQuick Check:
Clear flag = set to 0 [OK]
- Using comparison operator '==' instead of assignment
- Calling undefined functions to clear flags
- Confusing clearing with resetting the whole system
Consider the following code snippet that runs at system startup:
if (WDT_RESET_FLAG) {
recover_from_watchdog();
WDT_RESET_FLAG = 0;
} else {
normal_startup();
}What will happen if the system was reset by the watchdog timer?
Solution
Step 1: Check condition when watchdog reset flag is set
IfWDT_RESET_FLAGis true (non-zero), theifblock executes.Step 2: Follow code logic inside the
The functionifblockrecover_from_watchdog()is called, then the flag is cleared by setting it to zero.Final Answer:
The system calls recover_from_watchdog() and clears the flag -> Option BQuick Check:
Flag set = recover and clear flag [OK]
- Assuming normal_startup() runs after watchdog reset
- Thinking system hangs without recovery
- Believing system resets again immediately
Identify the error in this watchdog reset recovery code snippet:
if (WDT_RESET_FLAG = 1) {
recover_from_watchdog();
WDT_RESET_FLAG = 0;
}Solution
Step 1: Analyze the if condition syntax
The condition uses '=' which assigns 1 to the flag instead of comparing it.Step 2: Understand the impact of assignment in condition
Assignment always returns true, so the if block runs every time, ignoring actual flag state.Final Answer:
Using assignment '=' instead of comparison '==' in the if condition -> Option AQuick Check:
Use '==' for comparison in if conditions [OK]
- Confusing '=' (assign) with '==' (compare)
- Forgetting to clear the flag after recovery
- Misplacing semicolons inside if statements
You want to implement a watchdog reset recovery that logs the reset cause and safely restarts the system only if the reset was caused by the watchdog. Which sequence of actions is correct?
Solution
Step 1: Check the watchdog reset flag at startup
This tells if the reset was caused by the watchdog timer.Step 2: Log the reset cause and clear the flag before restarting
Logging helps diagnose issues; clearing the flag prevents repeated recovery loops.Step 3: Restart the system safely after handling the flag
This ensures the system restarts only after recovery steps are done.Final Answer:
Check watchdog reset flag, log reset cause, clear flag, then restart system -> Option DQuick Check:
Check flag -> log -> clear -> restart [OK]
- Restarting before clearing the flag
- Logging after restart (won't execute)
- Ignoring the flag and restarting blindly
Ready to prove it?
Pass the test and this pattern moves unknown
