After migrating to 0.22, init_psram hangs (esp32s3)

[yanshay]

I migrated an application I'm developing for esp32s3, to 0.22 .

To get it to compile it was all technicalities as in the migration instructions.
To get it to link I had to remove the link with rom_functions.x, I didn't see it documented anywhere but it wasn't found and linked without it.

When I run the code it starts and hangs in init_psram. There isn't much going on before that initialization, this is all the code that runs:

#[esp_hal_embassy::main]
async fn main(spawner: Spawner) {
    esp_println::logger::init_logger_from_env();
    info!("Application Started");

    let mut peripherals = esp_hal::init({
        let mut config = esp_hal::Config::default();
        config.cpu_clock = CpuClock::max();
        config
    });
    info!("peripherals Created");

    // IMPORTANT: PSRAM need to be initialized first, so 'Normal' allocations will use the region
    let (start, size) = psram::init_psram(peripherals.PSRAM, psram::PsramConfig::default());
    info!("Initialized psram");
    init_psram_heap(start, size);
    info!("Initialized psram heap");
...

The log output that comes out is as below, and then the program hangs and doesn't continue further (so "Initialized psram" log isn't reached).

INFO - [src/main.rs:118] Application Started
INFO - [src/main.rs:125] peripherals Created

Anything changed with psram initialization?

[bjoernQ]

Regarding PSRAM the diff doesn't show relevant changes: v0.21.1...v0.22.0

Regarding the rom-functions the migration guide chapter is here: https://github.com/esp-rs/esp-hal/blob/main/esp-wifi/MIGRATING-0.10.md#no-need-to-include-rom_functionsx-manually

[yanshay]

that doesn't look bad unfortunately. Are you using a custom partition table btw? (shouldn't make a difference however)

Yes, here it is, but I used it also in the small example that worked and it didn't have the same effect.
Did I do it right? (even if not related to this issue). lic and map sections are for my application use so used 0x40 as I understood required from the documentation.
while at it, is the nvs required when using esp-hal?

# Name,   Type, SubType, Offset,  Size, Flags
# Note: if you have increased the bootloader size, make sure to update the offsets to avoid overlap
lic,      0x40, 0x01,    ,        0x1000,
map,      0x40, 0x01,    ,        0x10000,
nvs,      data, nvs,     ,        0x6000,
phy_init, data, phy,     ,        0x1000,
factory,  app,  factory, ,        3M,

[bjoernQ]

The partition-table looks fine.

One thing you could try in psram.rs - adding the line before the debug output:

        start += MMU_PAGE_SIZE;
        debug!("PSRAM start address = {:x}", start)

[yanshay]

It didn't make a difference. Still hangs.
For test purpose, is it possible to disable that cache of the PSRAM and see if it works w/o the caching?

[bjoernQ]

interesting - the results from readelf and the output in psram_log.txt didn't match so this was an idea - but they are not from the exact same binary

PSRAM and flash access always have to be done through the cache

Since it still might be a miscompile you could also try a different opt-level and lto settings

[yanshay]

Since it still might be a miscompile you could also try a different opt-level and lto settings

I had:

[profile.release]
codegen-units = 1
debug = 2
debug-assertions = false
incremental = false
opt-level = 3
lto = 'fat'
overflow-checks = false

Changing lto to thin made it work !
Changing opt-level to 's' (keeping lto as fat) also made it work! Also made a large reduction of image size, over 20%.

I don't know if that means miscompile, but it looks like it solved the issue.
Maybe it's image size as both reduced image size (though lto not as significant)?

Changing opt-level to 2 (keeping lto as fat) didn't work.

Which is better to use then? I understood from #2234 (reply in thread) that esp-wifi needs high opt levels.
So is it better to move lto from 'fat' to 'thin' or change opt-level to 's'?

[bjoernQ]

My gut feeling is, it's not directly related to the code size. I can locally force the PSRAM to be mapped where previously flash was mapped which of course creates weird crashes but there is nothing in the code which would make that happen in real life.

Optimization optimizes the code in many hard to reason about ways (in multiple passes) - don't know how to track that down in a big codebase (while it would be great to know what exactly triggered the behavior to get that fixed for future builds)

For esp-wifi anything but 0 and 1 should work

[yanshay]

Thanks, and thanks so much for sticking with me so long to get this resolved!

[relufi]

The partition-table looks fine.分区表看起来不错。

One thing you could try in psram.rs - adding the line before the debug output:您可以在 psram.rs 中尝试一件事 - 在 debug 输出之前添加一行：

        start += MMU_PAGE_SIZE;
        debug!("PSRAM start address = {:x}", start)

I am also experiencing the same issue when using ESP32S3 and ESP-HAL 0.22, and the solution "start += MMU_PAGE_SIZE;" works for me, thank you.