sdc-g commented on PR #15985: URL: https://github.com/apache/nuttx/pull/15985#issuecomment-2731615130
Hi @chirping78 Thank you so much. It's so happy to discuss with you~ > please check the latest master code: xtensa_swint is now triggered by syscall, not by wsr intset. > syscall is a level1 interrupt. I'm also noticed that change. So current system only level-1 interrupt and syscall, both can re-set PS.EXCM to 0 by rfe, right? > If new task be resumed by level2 and above: rfi will restores the PS from EPS[N] and jump to the address in EPC[N]. Problem will be here, after the new task be resumed, the PS.EXCM bit is still set. If window rotation related instruction is executed, error will arise. I'm still wonder what happens while high level interrupt handling then switch to new thread context. Does it really happens? what is the value of EPS[N] then? Here is my consideration, from Level-1 interrupt and syscall view, it is a little bit strange to overwrite PS.EXCM to 0 and then set it to 1. I can understand that we are fixing same issue since I prepare one similar commit internally before (without overwrite, but set PS.EXCM to 1 in level-1 case), and also let Espressif guy reviewed. But this PR align with ESP-IDF, so probably, another choose is use it as formal one but remove _xtensa_syscall_handler/_xtensa_level1_handler overwrite/set PS.EXCM code. So I suppose the key point here is what is the impact for level-2 and above? -- 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
