tmedicci commented on PR #14672: URL: https://github.com/apache/nuttx/pull/14672#issuecomment-2554104315
> Actually I found these points during the evolution of this PR. You can see from the test history there are many asserts and panics in the history version. You can try to remove these two snippets, then you will meet the errors that I have met. Thanks for the explanation. I'm convinced about the need for the following section that sets PS.EXCM to 1 before `_xtensa_context_restore`: >``` > /* Set PS.EXCM to 1 */ > > movi a3, PS_EXCM_MASK > l32i a4, a2, (4 * REG_PS) > or a4, a3, a4 > s32i a4, a2, (4 * REG_PS) > ``` But, I still couldn't figure out the need for the section that clears it after `_xtensa_context_save`: > ``` > + /* Overwrite the PS saved by the exception entry. */ > + > + movi a2, ~PS_EXCM_MASK > + l32i a3, sp, (4 * REG_PS) > + and a3, a3, a2 > + s32i a3, sp, (4 * REG_PS) > + > ``` See, as you correctly pointed out, we are modifying it on the saved registers in the stack. `dispatch_c_isr` calls `ps_setup` that clears the current PS.EXCM bit (and sets the `INTLEVEL` to `EXCMLEVEL` in the PS register), so an exception can occur while handling the interrupt (as expected) but another interruption can't because of the `INTLEVEL`. Considering that a level-1 interrupt occurred and then an exception occurred during its handler, the first saved set of registers wouldn't be used to restore any context, right? Am I missing something here? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: commits-unsubscr...@nuttx.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
