2025-06-17 8:31 AM
I've setup the FMC peripheral of an STM32H7 to read registers from an FPGA by creating a faux SRAM interface on the FPGA. This works just fine so long as the FPGA has no issues but if, say, the FPGA is unprogrammed or the FPGA data bus gets hung, this forces the STM32 to hang. It doesn't seem to be able to recover in this event.
Is there a way to timeout the memory bus/FMC peripheral to recover from this?
Solved! Go to Solution.
2025-06-17 11:16 PM
Is there a scenario where FPGA would become non-operational while the board is up and running?
If not, it should be sufficient to test NWAIT state once at the reset - if it's active, then FPGA is down so you should not use the FMC.
If it's the other case, as there's no timeout built into the FMC hardware(*), and the WAIT may propagate to the originator (usually processor) and stall it indefinitely, unfortunately, the only way out of that is watchdog reset.
JW
(*) probably - the FMC/FSMC peripheral varies in details between STM32 families and even STM32 models within a family, so you should check in your STM32's RM, but I am not aware of any of them having timeout built in
2025-06-17 8:45 AM - edited 2025-06-17 8:53 AM
Hello,
Why are you considering if the FPGA is unprogrammed the data bus hangs? If you are in SRAM mode you can normally read and write even without any device connected. Except if you are using the NWAIT, in that case there is no way to recover except to reset the CPU for example using watchdog.
2025-06-17 9:31 AM
I am using the NWAIT. We do have a watchdog but I was looking for a way to recover that was more graceful.
Are there design considerations around removing the NWAIT? Is it just a little slower (because of the need to restart the transaction each time)?
2025-06-17 3:22 PM
Remove the NWAIT usage and consider to lengthern as much as possible the FMC timing to match the FPGA access timings.
2025-06-17 11:16 PM
Is there a scenario where FPGA would become non-operational while the board is up and running?
If not, it should be sufficient to test NWAIT state once at the reset - if it's active, then FPGA is down so you should not use the FMC.
If it's the other case, as there's no timeout built into the FMC hardware(*), and the WAIT may propagate to the originator (usually processor) and stall it indefinitely, unfortunately, the only way out of that is watchdog reset.
JW
(*) probably - the FMC/FSMC peripheral varies in details between STM32 families and even STM32 models within a family, so you should check in your STM32's RM, but I am not aware of any of them having timeout built in