Unable to boot Rust app on MCH2022 badge (ESP32-WROVER)

[jhaand]

Hi,

At the moment I'm a bit puzzled on how to continue.
For the hacker festival MCH2022 the organization works on a badge designed around an ESP32. It has a complete ecosystem with app store and custom launcher. Which means that you need to upload apps via webusb or the app store, not esptool.py. The badge features an ESP32-WROVER, FPGA, Display and RP2040. You can find more information here:
https://badge.team/docs/badges/mch2022/

This year it's also possible to upload binary apps to it instead of only Micropython ones. With the recent developments of Rust for the ESP32, I thought it was a cool idea to write a Rust app for the badge.
I try to write an app for the badge in Rust in the following repository:
https://github.com/jhaand/rust4mch

However, when I try to upload the app and run it, it doesn't work. It looks like the ESP32 resets, tries to start the app at the appropriate address and then the watchdog resets the bootloader to the normal launcher after 9 seconds.

The logging shows the error:

(456) cpu_start: Pro cpu up.
(460) cpu_start: Starting app cpu, entry point is 0x4008324c
(0) cpu_start: App cpu up.
-----> Wait for 9 seconds and reboot.
(11) boot: ESP-IDF v5.0-dev-1082-g9f303290d8 2nd stage bootloader
(12) boot: compile time 22:18:28
(12) boot: chip revision: 3

See the attached full logging for more information.

As described in the documentation here:
https://docs.espressif.com/projects/esp ... artup.html

I'm able to load a simple Hello world example using the Arduino framework using the webusb upload tool. Just code a simple hello world over the serial port with 115200 baud in the Arduino IDE and export the .bin file.

My simple 'hello world' example in Rust does work when I upload it using esptool to an ESP32 NodeMCU. But it doesn't work when I upload the .bin using the webusb tool in the repository.

Currently I have no clue on how to continue further to investigate this.
Does anybody have an idea?

[ESP_Sprite]

I know very little on the Rust side of things, but the 'booting binary apps' is done using appfs, and I designed that. My guess is that this may be an issue in the assumptions the Rust subsystem makes about flash layout... The thing is that appfs uses a custom bootloader that sets the MMU in an unconventional way (in order to map the discontinuous app file regions to one continuous memory space map) and Rust may not expect that.

I'll see if I can poke someone on the Rust team, see if they know more.

[rpiloverbd]

You can raise the issue here too: https://github.com/jhaand/rust4mch