32Kb internal RAM "disappeared" when upgrading from 0.23.1 to 1.0.0

[yanshay]

I upgraded my application from 0.23.1 to 1.0.0 that uses esp32s3. It involved upgrading also embassy, esp-mbedtls and other related crates.
It is a pretty complex appliccation so can't provide a reproduced to the issue here.

Everything seemed to work until I performed a certain operation and it panicked on some DMA descriptor to an I8080 display which works fine until that momemt many times (since it keeps updating screen on changes). So I guessed it was some memory overrun.

I am using DRAM, DRAM2 and PSRAM in my application for heap with the order of PSRAM first, then DRAM2 and then DRAM (though tests were conducted also with DRAM and DRAM2 order swapped).

As I reduced my DRAM heap size issues changed, from that DMA issue to exceptions, then other panicks including a "Detected a write to the stack guard value on ProCpu".

I reduced heap considerably and things worked, so I increased and the last point it worked was exactly 32KB less than the heap I was able to use in 0.23.1 .

My 0.23.1 application runs on quite a few devices including ones where the entire heap is in use, so I don't think it failed in 1.0.0 just because in 0.23.1 I was lucky not to have memory overruns. It seems like something takes 32Kb.

I also used nm to see what allocates bss memory (so goes at expense of heap) - saw small differences due to async state, but nothing that could cause a 32kb difference. (I use cargo nm --release -- -S --size-sort | grep " b " for this).

So that left me with looking at the memory.x .
I tried both my old memory.x from 0.23.1 (which I had to use to get larger binary size as the limit there is 4MB), and the latest memory.x from for esp32s3. No major differences (except I had to force the ICACHE which in the past was default - isn't it set by default like it was in 0.23.1 ?).

I did find some 4kb less in the size of dram segment in the new memory.x (why?) but again, not 32KB.
I think dram2 is also a bit different but that should't affect the stack overrunning heap. (it is 74kb based on memory.x)

Any ideas what could be that reduced size for the heap? It looks like the stack is taking 32KB more (because heap is barely in use but still seems like stack overruns heap).
Maybe there is stack allocated automatically to the 2nd core (that I don't use and don't allocate myself)?

Thanks