stnolting

> if you scroll down in that reference above, you'll find a nice surprise: I saw that :wink: I was just concerned by this statement from "iCE40 SPRAM Usage Guide":...

I have just tested that with Lattice Radiant using the default bitstream options. I am using the Upduino setup from the repository and the [`hex_viewer`](https://github.com/stnolting/neorv32/tree/master/sw/example/hex_viewer) program to manually read/write data...

But I think my reconfiguration scenario is considered "cold boot", right? @juanmard could you maybe try this with your warm-boot setup? 😉

> @stnolting see https://github.com/juanmard/neorv32/blob/warmboot/setups/examples/neorv32_iCESugar_BoardTop_MinimalBoot.vhd#L180-L185 Right :smile: Shouldn't be so complicated... I will try that with Radiant and use the WARMBOOT primitive to just reload the original bitstream.

> Yes, in that scenario it is as if a "cold boot" was made. 😉 I thought so 😅 Anyway, I made the **_redundant_** discovery cold boot does not preserve...

I have just tested your fix. Looks good so far, but there is a problem with the `ebreak` instruction. When running the [processor_check](https://github.com/stnolting/neorv32/tree/main/sw/example/processor_check) program via GDB the program enters debug...

I think this is because of a false `xepc` (trap return address) assignment. The EBREAK-TRAP and the SINGLE-STEP-IRQ might arrive at the same time here, but EBREAK seems to be...

> I didn't mean to hurt your eyes. 😉 It is quite common in VHDL to start with default assignments and then overwrite stuff in 'if' statements. This is also...

I think the bug has been resolved by #327. If you agree, we can close this, right?

Great, thank you very much! :+1: