While testing the exception traps routines I ran into an odd problem with the SRAM2 parity check on an STM32L496. As part of a unit test I force a usage error by attempting to read from 0x3000 0000, an invalid address. The usage vector is called correctly, but it is followed by an NMI interrupt with the SPF SRAM2 parity flag set.
I clear the parity error with an unlock followed by writing '1' to SPF, which does work (according to GDB SFR dump, SPF is set to 0). As soon as I exit the NMI handler the parity error occurs again, forcing the CPU into an endless NMI loop.
I clear SRAM2 at runtime startup, using the hardware zero feature. This works since I do not receive any parity errors while running the application, which accesses SRAM2 as DMA buffers. The usage exception is handled properly if parity is disabled. I do wait for the SRAM2 erase to complete at startup.
First question: why does a bus usage exception trigger an NMI parity error? If I disable SRAM2 parity check in option bytes I do not see the NMIs.
Second question, how is an SRAM2 parity error cleared in the NMI handler? The reference manual is silent on this. I send the SRAM2 unlock sequence followed by writing '1' to SPF in the SYSCFG register. This only seems to last as long as the NMI handler is running. An exit back to the usage exception handler immediately jumps to NMI again, with SPF set.
Jack Peacock
