Boot_Loop when rom is failing to load.

[NoNamedCat]

I think that when the execution start the best option is to show the menu. Sometimes when the emulator fails to load a rom to the app0 partition fails to boot and the user needs to reprogram that partition using the arduino IDE. so... if the menu have an option to format that partition, and the emulator menu shows at start (No loading the rom) is a good option to fix this issue.

BTW i think that if the audio pin is mapped to the IO17 and make free the IO18, we can use the standart pins for SPI protocol making it easy to atach a SD card to that pins. Im trying to understand the CRAPFS part of the code to load roms from the SD card.

[CornN64]

Good point. I just had it happen to me for a second time. The only way out is to wipe the whole SPIFFS and upload all the stuff again. After lots of googling I found a working source for compressing the ROM images "miniz" that are stored in the media.h file. (https://github.com/richgel999/miniz/releases -> example3.exe -l10 c rom.nes rom.nez and then paste the hexdump in the media.h file). Would have been nice to keep them compressed and only unpack them once they gets copied to the CRAPFS to save space on the limited SPIFFS. This of course will not matter if one adds and SD card with plenty of space...

I used IO17, 21, 22 and 27 for the hardwired NES/SNES controllers but that pins can be moved as well I suppose...

[demik]

I've ran into this issue as well and traced the main issue.

It is indeed caused by CrapFS who does overwrite in some situations the data from the spiffs partition. Then you get into that boot loop because your ROM files are corrupt. This is exacerbated by the default Arduino partition scheme:

# Name,   Type, SubType, Offset,  Size, Flags
nvs,      data, nvs,     0x9000,  0x5000,
otadata,  data, ota,     0xe000,  0x2000,
app0,     app,  ota_0,   0x10000, 0x140000,
app1,     app,  ota_1,   0x150000,0x140000,
spiffs,   data, spiffs,  0x290000,0x160000,
coredump, data, coredump,0x3F0000,0x10000,

The app1 is smaller than the spiffs partition. Let's say you packed a lot of stuff on your spiffs partition and it is full of ROMs, when loading the last ROM(s) from the file menu, the code will attempt to write that into the app1 partition.

Let's say the first free space block is at 0x150000 + 0x130000 and your ROM file size is 0x30000, this will override from 0x150000 + 0x130000 + 0x30000 to that's 0x2B0000. That's way into the the spiffs range (= corrupt unreadable ROMs now)

CrapFS also uses the first 64KB of data and align the other ROMs to 64KB multiples as well, so the app1 actually requires quite more space than the spiffs to not get into this issue (has to fit all ROMs + CrapFS header + block alignements)

As far as I understand the code, there is no overflow check in the code hence why that happens. Without adding an SD card, one possible solution is to alter the partition scheme.

I've had bullet proof success with the following method:

1. erase flash before changing spiffs content
2. change the partition scheme to the following one:

# Name,   Type, SubType, Offset,  Size, Flags
nvs,      data, nvs,     0x9000,  0x5000,
otadata,  data, ota,     0xe000,  0x2000,
app0,     app,  ota_0,   0x10000, 0x90000,
app1,     app,  ota_1,   0xA0000,0x1B0000,
spiffs,   data, spiffs,  0x250000,0x1A0000,

This reduce the app partition size (make sur the code is below 589824 bytes, that's tight!), and increase app1 et spiffs. This should also help you to fit one or two more ROMs than the default setup (now max useable space increases from 1280KB to 1664KB)

3. load every rom from first to last
4. reload the first ROM.

if it's corrupt, then you have too much data on your spiffs, despite the app1 partition being bigger. Remove one or two roms, retry from 1.

5. check offsets on console to be sure the CrapFS code didn't override the spiffs data. Example:

...[redacted]...
00110000 00060010 /nofrendo/super_mario_bros3.nes
00180000 0000C010 /nofrendo/teris.nes

end of Tetris ROM is 00180000 + 0xC010 = 0018C010 aligned to the upper CrapFS block so end if actually 00190000. We are good

Hope that helps!

[NoNamedCat]

Can you show us the code?

[demik]

There is no code involved as far as the partitioning workaround goes. Only messing with your IDE

You need to add the new partition table to your Arduino IDE. (Used 1.8.14 + ESP 1.0.4).

1. create a esp_8_bit.csv into this directory with the "fixed" partition tables above in this directory:

C:\Users\<Username>\AppData\Local\Arduino15\packages\esp32\hardware\esp32\1.0.4\tools\partitions

with this content:

# Name,   Type, SubType, Offset,  Size, Flags
nvs,      data, nvs,     0x9000,  0x5000,
otadata,  data, ota,     0xe000,  0x2000,
app0,     app,  ota_0,   0x10000, 0x90000,
app1,     app,  ota_1,   0xA0000,0x1B0000,
spiffs,   data, spiffs,  0x250000,0x1A0000,

2. edit the following file:

C:\Users\<Username>\AppData\Local\Arduino15\packages\esp32\hardware\esp32\1.0.4\boards.csv

Find the board you are using (I'm using a PICO based one) and register the partition scheme at the end of your board declaration like this:

---[redacted---
pico32.menu.PartitionScheme.min_spiffs=Minimal SPIFFS (Large APPS with OTA)
pico32.menu.PartitionScheme.min_spiffs.build.partitions=min_spiffs
pico32.menu.PartitionScheme.min_spiffs.upload.maximum_size=1966080
pico32.menu.PartitionScheme.esp_8_bit=esp_8_bit (Optimised flash usage)
pico32.menu.PartitionScheme.esp_8_bit.build.partitions=esp_8_bit
pico32.menu.PartitionScheme.esp_8_bit.upload.maximum_size=1966080

The new partitioning scheme should now be available inside Arduino IDE. Clearing the flash before re uploading anything is a good idea