[FEATURE] exception handler roadmap.

[lgirdwood]

Today exception handlers spin the DSP and emit an IPC error. We can do better. (pls add other items here)

• [x] Call Zephyr stack and context dump
• [x] Write stack and context to SRAM Window (and power SRAM ON if OFF)
• [x] 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.
• [x] 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

[cujomalainey]

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]

@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]

@eddy1021 FYI for testing

[lgirdwood]

@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.