This might be a question for @Mr.Blinky or @filmote but figured I’d ask in general:
I’m working on a raw cart modifier to go along with the toolset I’m working on, so you can more easily add games to the cart image on your FX without losing FX saves (if there are any). I’m aware there are already things out there that do it, I just want to make one too!
Anyway, will the bootloader still accept serial commands for flashing the FX if I totally mess up the format of the flash cart? Like, if the ARDUBOY header is there but the rest of the header is very broken, the bootloader won’t like… get into an infinite loop will it? Or, is there a way to boot in “bootloader only” mode and not try to read from the FX flash?
LOL … I am not sure I am qualified to answer but I will take a stab.
If the FX is screwed up, I think the bootloader will be unaffected as it is ‘burnt’ onto the device - not the FX chip. I tmay check to see if the FX is present and responding though which could be an issue if it is checking the integrity of the data on the FX chip and not just that it is present.
Again, I think so. The devices must have a bootloader prior to flashing the FX the first time, don’t they? In which case is it ‘safe’ to assume that it handles empty or messed up FX chips?
How’s that for a non-answer … maybe, possibly, surely, I think … @Mr.Blinky ??
You can mess up the bin file and still flash it, it does not check integrity.
When uploading the bin you are flashing the external memory, it doesn’t effect any of the memory that is on the 32u4.
The loader menu is contained entirely within the bootloader, every time you start the Arduboy FX you are inside of the protected memory of the 32u4. The only way you can damage the bootloader is by uploading a corrupted or malformed .hex file to the 32u4.
Worst thing you can do is make a game in the list loop back to it self or a previously game in the list. That would effectively freeze the game menu selection once you try to choose the next game in the list. You can recover from that by turning power off and on and upload a new bin file.
2nd worst thing you could do is corrupt a hex file. the bootloader does not check integrity and bluntly flashes and executes the code. but the bootloader doesn’t allow flashing the bootloader area so effectively only the selected sketch will crash. You can recover by turning power off and on and flash a new bin file.
finally if you’d accidently change the list / category of the first file header of FX storage to a non zero value. The USB boot logo will just pop up and you wont be able to select any games. You can just upload a new bin file.
Ah thank you for the info, but that’s not what I mean (I would hope flashing external memory doesn’t affect the on-chip flash containing the bootloader!). I mean that, if I flash a faulty image to the FX, when the bootloader starts and tries to enter the ‘selection’ menu, is it possible that it will read the FX flash image and get into some kind of loop that doesn’t allow it to process commands over serial.
Ah this is what I was considering. So the menu program doesn’t try to look “forward” in the flash until you actually move around? This is good.
This is something else I was wondering about. So even if there’s a valid ‘ARDUBOY’ text in the first bytes indicating a slot header, it will still not boot into the menu if the category isn’t 0? That’s cool, good to know!
Thank you all for the info! I have far less trepidation now, hopefully I can try out neat stuff!
