ECU Reset
There are several things that can cause OpenECU to reset. These can be monitored with the Reset block, which provides an output flag for the reset conditions listed below. The flag will be set to 1 for whichever event caused the last reset.
Flag |
Cause |
How to debug it |
power_reset |
Loss of power to the module |
Check for intermittent power connections |
watchdog_reset |
Internal watchdog was not serviced in time |
Check CPU usage (see below) |
access_reset |
Software tried to access an invalid memory location |
|
fp_reset |
Software tried to to perform an invalid floating point operation |
|
mem_reset |
Memory corruption |
RAM: problem may go away on reset |
forced_reset |
Application commanded the ECU to reset |
Check input to Reset block |
unknown_reset |
Any reset that isn't one of the above |
Check for stack overflow (see below) |
If the Application software is unable to run long enough to read the reset flags, try reading the Flash Code Output to determine the ECU state.
Watchdog Reset
The ECU has an internal watchdog that must be serviced periodically. If the Kick Watchdog block is not present, then the OpenECU platform will automatically update the watchdog periodically. If the CPU load is too high, then the watchdog may not get updated, which will force the ECU to reset. The CPU load can be monitored with the Processor Loading block.
Infinite loops in the application software can also cause watchdog resets. This is typically not possible in pure Simulink models, however it could happen with 3rd party libraries or custom code blocks.
Stack Overflow
There isn't a way to detect a stack overflow, but you can monitor stack usage with the Stack Used block to see how close to the limit the application code is, or use the built-in monitoring variables as described here. The default stack size is 8192 bytes, which may be too small for large or complex applications. To change the stack size, see How do I change the stack size? See also Stack Size
Monitoring Resource Usage