Function app_desc 

pub fn app_desc() -> &'static EspAppDesc

Reads back the descriptor app_desc! emits.

app_desc! expands to a static named ESP_APP_DESC at its call site (i.e. in the binary, not this crate), so this reads it back by its linker symbol (esp_app_desc, EspAppDesc is #[repr(C)]) rather than by path — the one way a BSP function can reach a descriptor the consumer created. Requires app_desc! to have been invoked somewhere in the binary: otherwise this fails to link, not silently reads zeroes.

This indirection matters beyond just “how do we reach it”: reading ESP_APP_DESC via an extern symbol, rather than by path from inside the same crate that defines it, is what keeps app_elf_sha256 correct. espflash patches that field into the flashed image after compilation — the compiler only ever sees the macro’s zero initializer. A same-crate path read of a static with a compiler-visible initializer is free to const-fold to that initializer (needing a read_volatile to stop it); an extern read of a symbol whose initializer lives in a different compilation unit has no initializer to see in the first place, so the hazard cannot arise — no volatile needed. version has no such concern (nothing patches it post-link), but app_elf_sha256 does: don’t “simplify” this back to a path reference.