Repository navigation
romfs deploy: works over WebREPL while a program runs from /rom - #220
Merged
Merged
Conversation
Over WebREPL there's no soft reset before a deploy, so a program imported from /rom kept running between the deploy's commands. Its timers ran bytecode the deploy had just erased, and the names it had brought in read back as erased flash, so the board hung with a blank partition. A deploy that sends one command per 4 KB chunk is also left half-written, under a valid header, when the link drops midway. Over WebREPL and BLE, and over serial when modules from /rom are still loaded, the erase and write now run on the board inside one scheduled callback, which keeps every other callback out. The image streams through it, the header chunk goes last, and the board resets when it's done, or when the host gives up and sends Ctrl-C. On an Arduino GIGA R1 running its launcher from /rom, two WebREPL deploys of a 1,883,072-byte image finished in 50 s and 49 s, the image read back identical and the board came back up running the launcher from it. Fixes #215
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
mpftp romfs deployover WebREPL now works on a board whose program runs from/rom. Before, it hung the board and left the partition blank. When it's done, the board resets and comes back up running the new image.Over WebREPL nothing soft-resets the board before a deploy, so the running program carries on between the deploy's commands. Its timers ran bytecode the deploy had just erased. The names it had imported also kept their text in the image: on the first run of this change, a one-letter marker string came back as
0xffright after the erase. And mpremote's deploy sends one command per 4 KB chunk with the header first. When a weak Wi-Fi link dropped at 528 KB, which happened once in two plain runs here, it left a half-written image under a valid header.So over WebREPL and BLE, and over serial when modules from
/romare still loaded, the erase and the writes now run on the board inside one scheduled callback. While it runs, no other callback can. The image streams through it as base64 deflate chunks, each acknowledged, with the header chunk last, so an interrupted deploy leaves nothing to mount. Its markers are bytes made before the erase. The board resets at the end, and also when the host gives up after 30 quiet seconds and sends Ctrl-C. A serial deploy with nothing from/romloaded still goes through mpremote as before.I tested it on an Arduino GIGA R1 WiFi with its launcher running from
/rom(27 modules loaded). Two WebREPL deploys of a 1,883,072-byte image finished in 50 s and 49 s. The partition's SHA-256 matched the image, and after the reset the launcher was running from it again. The planted stall on the first version (the0xffmarker) ended with the Ctrl-C path: the board reset itself and came back on Wi-Fi with no power cycle.romfs queryover WebREPL reads the new image. The new unit tests run the board half of the protocol under CPython against a fake partition. They fail if the header doesn't go last or the deploy doesn't go through the callback. The full CLI suite passes and ruff is clean. I didn't test over BLE, or a partition object withioctl(esp32).Fixes #215