The NMI can asynchronously interrupt the load/store exception handler. This does occur frequently as the NMI handler code does invoke load/store exceptions, and the load/store exception handler is heavily used. This was corrupting the load/store exception handler saved state and thus randomly corrupting registers a0 to a6 of the interruptee.
Re-entry of the load/store handler was quite frequent so this one needs fixing. Testing or review feedback would be welcomed? This PR implements a different strategy to the SDK fix and might be more efficient and supports multiple re-entry via an NMI.
The sdk code also appears to handle NMI re-entry too, but that seems a separate issue. Not yet sure where that is a problem, perhaps very quick repetition of an NMI before the handler disables it, or perhaps on the exit path after re-enabling the NMI but before restoring state from the NMI stack? Shall look into that separately.
The NMI can asynchronously interrupt the load/store exception handler. This does occur frequently as the NMI handler code does invoke load/store exceptions, and the load/store exception handler is heavily used. This was corrupting the load/store exception handler saved state and thus randomly corrupting registers a0 to a6 of the interruptee.
Re-entry of the load/store handler was quite frequent so this one needs fixing. Testing or review feedback would be welcomed? This PR implements a different strategy to the SDK fix and might be more efficient and supports multiple re-entry via an NMI.
The sdk code also appears to handle NMI re-entry too, but that seems a separate issue. Not yet sure where that is a problem, perhaps very quick repetition of an NMI before the handler disables it, or perhaps on the exit path after re-enabling the NMI but before restoring state from the NMI stack? Shall look into that separately.