EV3 USB hacks #2356

dlech · 2026-01-04T21:22:23Z

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.

dlech · 2026-01-04T22:42:52Z

src/firmware/sagas.ts

+    // 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


Suggested change

const eraseSize = sectorSize * 2; // flash memory sector size

const eraseSize = sectorSize * 2;

jaguilar · 2026-01-05T03:38:10Z

Affirmed that with 5ed3861, I can successfully flash the EV3 from my Windows computer.

laurensvalk · 2026-01-05T08:57:00Z

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 0 it won't show the percentage. It just shows progress:

laurensvalk · 2026-01-05T09:03:35Z

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 512 bytes?

dlech · 2026-01-05T14:49:43Z

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%.

Yes, we never had such a slow first step on other hubs, so could use some work.

Would things be a lot simpler if we write in chunks of 512 bytes?

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).

laurensvalk · 2026-01-05T15:11:35Z

Ah, makes sense now. Thanks!

laurensvalk · 2026-01-23T09:12:42Z

src/firmware/sagas.ts

+
+    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).


Maybe I'm misunderstanding this, but this doesn't seem quite right?

If we let one superchunk be S = 2 * 64 * 1024. Then for any firmware size X * S, we have remainder = 0, so we don't add padding.

Say our firmware size is X = 4, for example. Then remainder is 0 but the last write chunk will be (4 * 2* 64 * 1024) % 1018 = 18, so that is a small write that would cause the bug.

It seems that the assumption here is that only the last two chunks matter, but that is not universally the case.

Hmm, I suppose we're sending small packets at the end of every super chunk to make that work?

This all seems a little more complicated than it needs to be 😄 I'll have a look at an alternative.

Well, I guess you've studied this pretty well at this point and since it is working, let's proceed :)

laurensvalk · 2026-01-23T12:37:47Z

Since this is titled EV3 USB hacks, I've added two more. I propose to include this PR in the next beta/labs build to see where things stand. We can restore the USB reset if we find that we need to.

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.

If we try to connect too soon, we get security errors.

This operation does not work on Windows, and does not appear to be crucial on other platforms either.

dlech · 2026-01-23T15:18:36Z

src/usb/sagas.ts

    if (hotPlugDevice !== undefined) {
        yield* put(usbHotPlugConnectPybricks());
+
+        // Even though we get the connect event, the browser does not


Does this only apply to Linux?

We should test on a slow machine like a Raspberry Pi to make sure the delay is long enough.

And we should report this as a bug to Chromium. Then it could be fixed in a reliable way. For example, it could be that they are using the udev add event instead of bind that triggers the event before udev rules have run instead of after.

dlech · 2026-01-23T15:20:27Z

src/usb/sagas.ts


    exitStack.push(() => usbDevice.close().catch(console.debug));

-    // Always reset the USB device to ensure it is in a known state.


Since we already have a good idea of what the solution will be to replace this, I think we should go ahead and implement it now instead of doing a buggy release.

I don't currently know what the solution is, but I'm happy to wait if you think we have one.

I've not been able to reproduce any issues without the reset so far.

dlech · 2026-01-23T15:22:29Z

src/usb/sagas.ts

        // if there is exactly one Pybricks device connected, we can connect to
        // it, otherwise we should let the user choose which one to connect to
        if (pybricksDevices.length === 1) {
+            // REVISIT: Device is passed as hotplug device, even though it is


I don't understand what needs to be revisited here. Is the problem just the technicality in the naming?

No. This is not a hotplug. This gets called when you load the page and the hub is already connected. So we don't need the hotplug delay (but it doesn't hurt to keep).

It could be (very unlikely but still possible) that the USB was plugged in at the same time the page was loaded, so probably best to keep it and not differentiate.

This was referenced Jan 4, 2026

[Bug] EV3 firmware installation sends bad status values pybricks/support#2375

Open

feat(flash): Switch to sector-by-sector flashing c4ev3/ev3duder#47

Open

dlech commented Jan 4, 2026

View reviewed changes

dlech force-pushed the dlech branch from 72854cf to 5ed3861 Compare January 4, 2026 23:27

laurensvalk reviewed Jan 23, 2026

View reviewed changes

laurensvalk force-pushed the dlech branch from 5ed3861 to 3eaabc4 Compare January 23, 2026 12:35

dlech added 4 commits January 23, 2026 14:21

firmware/ev3: add extra progress report

e001642

Add an extra progress between erasing and writing. This makes the progress not stall for quite as long before progressing when flashing smaller firmwares.

laurensvalk force-pushed the dlech branch from 3eaabc4 to f751d1f Compare January 23, 2026 13:21

laurensvalk added 2 commits January 23, 2026 14:32

usb/sagas: Delay connection attempt on hotplug.

37de6a5

If we try to connect too soon, we get security errors.

usb/sagas: Don't reset USB device.

fcb0286

This operation does not work on Windows, and does not appear to be crucial on other platforms either.

laurensvalk force-pushed the dlech branch from f751d1f to fcb0286 Compare January 23, 2026 13:32

dlech commented Jan 23, 2026

View reviewed changes

	const eraseSize = sectorSize * 2; // flash memory sector size
	const eraseSize = sectorSize * 2;


		exitStack.push(() => usbDevice.close().catch(console.debug));

		// Always reset the USB device to ensure it is in a known state.

EV3 USB hacks #2356

Are you sure you want to change the base?

EV3 USB hacks #2356

Conversation

dlech commented Jan 4, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jaguilar commented Jan 5, 2026

Uh oh!

laurensvalk commented Jan 5, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

laurensvalk commented Jan 5, 2026

Uh oh!

dlech commented Jan 5, 2026

Uh oh!

laurensvalk commented Jan 5, 2026

Uh oh!

laurensvalk Jan 23, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

laurensvalk Jan 23, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

laurensvalk commented Jan 23, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

dlech Jan 23, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

dlech commented Jan 4, 2026 •

edited

Loading

laurensvalk commented Jan 5, 2026 •

edited

Loading

laurensvalk Jan 23, 2026 •

edited

Loading

laurensvalk Jan 23, 2026 •

edited

Loading

dlech Jan 23, 2026 •

edited

Loading