ESP32 Forum

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 into SRAM1 data (0x3FC88000) memory it will just hang, and I cannot figure out why. If I simply read the memory back and place it onto UART0 there is no issues, and I can even read the entirety of SRAM1 data memory (0x3FC88000 - 0x3FCEFFFF) but if I edit the memory in data memory then it will hang. My bootloader does not store any data but accesses peripherals and other sections of memory directly, this is by design. I also checked to ensure my stack is not the issue, the stack is nowhere near the section of memory I am editing, so it cannot be the issue. Also, I have my vector table in place and interrupts working, and there are no interrupts on the hang, meaning it's not stuck in a vector handler either.

Has anyone experienced this issue before writing their own bare-metal projects? I would love any kind of advice, please.

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

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

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.

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 reading the memory and storing a copy, zeroing it and then writing the same memory that was there before, this eventually caused a user exception interrupt but the INTERRUPT register is 0, so I have no idea what the interrupt is, just that it happens. This indicates some hardware component in parallel is accessing and requiring this memory, or at least that is my estimate.

This means that, without a doubt, there is read/write access. The issue is that there is something that is storing data that is being used. As I said previously it cannot be my stack nor my bootloader as the stack does not reach that far down and the bootloader does not store data in memory, it directly manipulates it.

If there is any idea as to what could be using this memory, I would love to know. I do not see anything in the TRM saying there is a component that uses that area of memory.

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.

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!

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 for the suggestion, first time working with JTAG.

I noticed that if I use JTAG to see more details on the registers like EXCCAUSE, EPC1, and EXCVADDR that it pointed to invalid instructions in my zeroing memory function. This was odd to me because I never touch that area so I should not be corrupting that memory. So, I uncommented the function call to those zeroing functions and then fired everything up again to discover that the functions are completely normal, there was no corruption and I found this odd because it was corrupted before.

Basically, the zeroing function is somehow editing instruction memory despite going nowhere near it. Which lead me to wonder what the content of the memory was that I was zeroing in data memory (around 0x3FC88440, +- 8 bytes). Since EPC1 and EXCVADDR showed me the issue was within the zeroing function I compared the memory in data memory to that function, turns out that it contains instructions, and not just any instructions, specifically instructions from my zeroing function!

This means that for whatever reason my data memory (which is not executable memory, according to TRM) contains instruction memory and if I zero that then it corrupts the instruction memory located in 0x40378000. I have no idea why this is happening.

On top of that, I checked to see the default settings for ICache and DCache. The TRM claims that those begin in blocks BLOCK0, BLOCK1 and BLOCK9, BLOCK10 respectively.

So unless the TRM is wrong about those beginning at SRAM0 and SRAM2 respectively, what else could be using that memory? I did not find a way for JTAG to explicitly tell me what hardware component is using that area.

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.

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 instruction bus and data bus, then what is the point of the segregation? Data bus has byte-by-byte access, instruction bus does not. Instruction memory says it's R/W/X, data memory is R/W. Also, it misrepresents the memory since it makes it seem like there's a memory segment for instructions and a memory segment for data... but in actuality, there is not.

That just simply does not make sense.

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 seems to be the issue.