EV3 USB hacks #2356
EV3 USB hacks #2356
Conversation
| // 384 bytes (triggered by 65536 % 1018 = 384). To work around this, we | ||
| // always erase two sectors to make the last chunk be twice as big | ||
| // (131072 % 1018 = 768). | ||
| const eraseSize = sectorSize * 2; // flash memory sector size |
There was a problem hiding this comment.
| const eraseSize = sectorSize * 2; // flash memory sector size | |
| const eraseSize = sectorSize * 2; |
Add a hack to not fail if the EV3 bootloader sends an echo of the request instead of the expected response. There is a known compatibility issue with the EV3 bootloader USB and, e.g. Windows with USB 3.0 ports. This apparently causes a race condition where commands that don't take long to process before sending a response will have the request echoed back instead of receiving the actual response. If this happens, we can ignore it and assume the command was successful. It just won't work, e.g. for the version command since that has a payload in the response.
Change from erasing 1 sector at a time to erasing 2 sectors at a time. This works around a USB issue where commands that don't take long to execute can receive an incorrect response. The point of erasing 2 sectors at a time is that when we write the data to the sectors that we just erased, the last (partial) chunk of data is now twice as large, which makes it take twice as long to write. This seems to be long enough to avoid the USB issue.
Add an extra progress between erasing and writing. This makes the progress not stall for quite as long before progressing when flashing smaller firmwares.
Add a function to pad EV3 firmware size to avoid potentially triggering bugs in the EV3 bootloader. When we do a download command with too small of a payload, the bootloader can send a bad response. We can work around this by ensuring that the firmware size is such that the last chunk is the maximum size. This way we never send a small chunk that could trigger the bug.
|
Affirmed that with 5ed3861, I can successfully flash the EV3 from my Windows computer. |
|
Thanks! This seems to be working, although I'm seeing a separate HID detection issue. I'll defer that to a separate issue. I noticed that the progress bar doesn't appear until after a few seconds when it hits 8%, so for a little while you're left wondering if anything happened. It would be nice to start at 0%. When I put in a dedicated progress at the start, there seems to be a separate bug that if progress is |
function computeEv3ExtraLength(firmwareLength: number): number {
// HACK: If the EV3 firmware size is not a multiple of 2 * 64KiB, then we
// need to add some padding to avoid possibly triggering a bug where small
// download payloads can cause bad replies. This is done by ensuring that
// the last chunk is 1018 bytes.
const maxChunkSize = 1018;
const eraseSize = 2 * 64 * 1024;
const remainder = firmwareLength % eraseSize;
if (remainder === 0) {
// Adding padding would cause an entire extra erase to be needed. Don't
// do that and rely on a a different workaround (always erasing two sectors).
return 0;
}
return maxChunkSize - (remainder % maxChunkSize);
}Would things be a lot simpler if we write in chunks of |
Yes, we never had such a slow first step on other hubs, so could use some work.
I tried that, but we get no response from the EV3 if the chunk size is anything other than 1018 (other than the last chunk). |
|
Ah, makes sense now. Thanks! |
Add a number of hacks to work around issues seen when flashing firmware on the EV3.
See individual commit messages for details.
Alternate to #2352.
The first patch on it's own should allow firmware flashing to complete without error (only warnings).
The rest of the patches aim to avoid triggering the warnings in the first place.