I did a test where I wrote 0xDEADBEEF to the end of my .text and then looked for the same value in data memory, and there it was.

I guess this is just me misunderstanding how the memory is represented but it feels like the documentation could've done a better job.

Thank you all for your help, this ...

SRAM1 is accessed over the data bus at 0x3fc88000 or the instruction bus at 0x40378000. It's the same physical memory. When you clear 0x3fc88000 you are also clearing 0x40378000.


That doesn't make any sense. If the case is it's the same physical memory but accessed differently by the ...

Have you tried debugging this using the JTAG port (embedded in the USB-serial-JTAG device)? I'd try using that to set a breakpoint on that address, see if anything else reads it.


All right, after looking into this with JTAG I found out interesting details I was not expecting. Thank you again ...

Have you tried debugging this using the JTAG port (embedded in the USB-serial-JTAG device)? I'd try using that to set a breakpoint on that address, see if anything else reads it.

Did not think of that...

I will come back after I do that, thank you for the suggestion!

I do not mean to bump up my own post, but I do have some news in the event someone else runs into the same issue.

I discovered that if I simply write the same exact memory to itself nothing happens, which indicates that the memory area itself is accessible both in read and write. Then I also tried ...

Also, I have my vector table in place and interrupts working,

The vector table doesn't reside in the SRAM1 you're overwriting, right?

No, I have it residing in instruction memory, 0x40378000.

Hello there!

I'm doing a project with my ESP32S3 that is bare-metal, and so as a result I have to develop the bootloader and kernel (or otherwise however I want to use the resources) myself.

In my bootloader I want to zero out sections of SRAM1 Data memory, but if I do this at around >1024 bytes ...