Repository navigation
[FEATURE] exception handler roadmap. #6743
Description
Today exception handlers spin the DSP and emit an IPC error. We can do better. (pls add other items here)
- Call Zephyr stack and context dump
- Write stack and context to SRAM Window (and power SRAM ON if OFF)
- Inform host and include any SOF application context error token (@aborisovich I'm calling this an error token today as I dont have a better name). This will depend on your error code work.
- Put the DSP into a recoverable state (e.g. mask, IRQ, stop timers, disable DMAs) so that host can reload FW or reboot without a power cycle.
- Invoke the GDB stub in polling mode (if in debug mode) - this allows further FW introspection
@thesofproject/steering-committee @kv2019i @nashif @andyross @mmaka1 @marcinszkudlinski
Activity
cujomalainey commentedon Dec 7, 2022
2 and 3 are definitely of interest here. Tracking a context token will be easier than identify which PC is the cause of the crash
kv2019i commentedon Jun 20, 2023
@lgirdwood I now marked items 1, 2 and 3 done. I'm not 100% about the "context error" token (FYI @aborisovich ). FW sends the standard IPC4 exception notification and we provide a standard Zephyr coredump in SRAM. So I'd say this provides ample application context, and is basicly matching what we can do with IPC3/4 protocol now. Please add a new task if you meant something more specific.
cujomalainey commentedon Jun 21, 2023
@eddy1021 FYI for testing
lgirdwood commentedon Jul 4, 2023
@kv2019i @cujomalainey so we are missing the GDB polling stub. I think we had some PRs in progress on Zephyr but never finished due to high priority work. Could be a Q4 item.