Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
89 changes: 78 additions & 11 deletions src/firmware/sagas.ts
Original file line number Diff line number Diff line change
Expand Up @@ -199,6 +199,25 @@ function* firmwareIterator(data: DataView, maxSize: number): Generator<number> {
}
}

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).
Copy link
Member

@laurensvalk laurensvalk Jan 23, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member

@laurensvalk laurensvalk Jan 23, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

return 0;
}

return maxChunkSize - (remainder % maxChunkSize);
}

/**
* Loads Pybricks firmware from a .zip file.
*
Expand Down Expand Up @@ -376,7 +395,14 @@ function* loadFirmware(
throw new Error('unreachable');
}

const firmware = new Uint8Array(firmwareBase.length + checksumExtraLength);
const ev3ExtraLength =
metadata['device-id'] === HubType.EV3
? computeEv3ExtraLength(firmwareBase.length)
: 0;

const firmware = new Uint8Array(
firmwareBase.length + checksumExtraLength + ev3ExtraLength,
);
const firmwareView = new DataView(firmware.buffer);

firmware.set(firmwareBase);
Expand Down Expand Up @@ -1107,16 +1133,33 @@ function* handleFlashEV3(action: ReturnType<typeof firmwareFlashEV3>): Generator
continue; // ignore empty reports
}

const length = event.data.getInt16(0, true);
let length = event.data.getInt16(0, true);
const replyNumber = event.data.getInt16(2, true);
const messageType = event.data.getUint8(4);
let messageType = event.data.getUint8(4);
const replyCommand = event.data.getUint8(5);
const status = event.data.getUint8(6);
const payload = event.data.buffer.slice(7, 7 + length + 2);
let status = event.data.getUint8(6);
let payload = event.data.buffer.slice(7, 7 + length + 2);

if (messageType === 0x01) {
// HACK: This works around a strange bug that can be triggered
// e.g. by USB 3.0 on Windows. Sometimes the EV3 bootloader will
// send the request back instead of the reply. In this case,
// fake the reply to avoid protocol errors. This seems to work
// as long as we aren't sending commands that have a reply
// with a payload (like reading version or checksum)

console.warn(
`Bad EV3 reply: length=${length}, replyNumber=${replyNumber}, messageType=${messageType}, replyCommand=${replyCommand}, status=${status}`,
);
length = 5;
messageType = 0x03;
status = 0x00;
payload = new ArrayBuffer(0);

console.debug(
`EV3 reply: length=${length}, replyNumber=${replyNumber}, messageType=${messageType}, replyCommand=${replyCommand}, status=${status}, payload=${payload}`,
);
console.info(
`Fixed EV3 reply: length=${length}, replyNumber=${replyNumber}, messageType=${messageType}, replyCommand=${replyCommand}, status=${status}`,
);
}

yield* put(
firmwareDidReceiveEV3Reply(
Expand Down Expand Up @@ -1208,9 +1251,17 @@ function* handleFlashEV3(action: ReturnType<typeof firmwareFlashEV3>): Generator
const sectorSize = 64 * 1024; // flash memory sector size
const maxPayloadSize = 1018; // maximum payload size for EV3 commands

for (let i = 0; i < action.firmware.byteLength; i += sectorSize) {
const sectorData = action.firmware.slice(i, i + sectorSize);
assert(sectorData.byteLength <= sectorSize, 'sector data too large');
// HACK: Ideally, we would erase one sector at a time to minimize required
// alignment and make the progress indicator smoother. However, there is a
// bug triggered, e.g. by USB 3.0 on Windows, that causes bad replies from
// certain commands. This bug happens sometimes when the payload size is
// 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
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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


for (let i = 0; i < action.firmware.byteLength; i += eraseSize) {
const sectorData = action.firmware.slice(i, i + eraseSize);

const erasePayload = new DataView(new ArrayBuffer(8));
erasePayload.setUint32(0, i, true);
Expand All @@ -1229,6 +1280,22 @@ function* handleFlashEV3(action: ReturnType<typeof firmwareFlashEV3>): Generator
return;
}

// Erasing takes about the same time as writing, so this will make the
// progress bar smoother.
yield* put(
alertsShowAlert(
'firmware',
'flashProgress',
{
action: 'flash',
progress:
(i + sectorData.byteLength / 2) / action.firmware.byteLength,
},
firmwareEv3ProgressToastId,
true,
),
);

for (let j = 0; j < sectorData.byteLength; j += maxPayloadSize) {
const payload = sectorData.slice(j, j + maxPayloadSize);

Expand Down
19 changes: 8 additions & 11 deletions src/usb/sagas.ts
Original file line number Diff line number Diff line change
@@ -1,5 +1,5 @@
// SPDX-License-Identifier: MIT
// Copyright (c) 2025 The Pybricks Authors
// Copyright (c) 2025-2026 The Pybricks Authors

import { firmwareVersion } from '@pybricks/firmware';
import { AnyAction } from 'redux';
Expand Down Expand Up @@ -77,6 +77,11 @@ function* handleUsbConnectPybricks(hotPlugDevice?: USBDevice): Generator {
// so that reducers still work correctly.
if (hotPlugDevice !== undefined) {
yield* put(usbHotPlugConnectPybricks());

// Even though we get the connect event, the browser does not
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

// appear to be ready to open the device right away, so we add a
// small delay before trying to connect.
yield* delay(100);
}

if (navigator.usb === undefined) {
Expand Down Expand Up @@ -151,16 +156,6 @@ function* handleUsbConnectPybricks(hotPlugDevice?: USBDevice): Generator {

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

// Always reset the USB device to ensure it is in a known state.
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

const [, resetErr] = yield* call(() => maybe(usbDevice.reset()));
if (resetErr) {
// TODO: show error message to user here
console.error('Failed to reset USB device:', resetErr);
yield* put(usbDidFailToConnectPybricks());
yield* cleanup();
return;
}

const [, selectErr] = yield* call(() => maybe(usbDevice.selectConfiguration(1)));
if (selectErr) {
// TODO: show error message to user here
Expand Down Expand Up @@ -655,6 +650,8 @@ function* handleUsbConnectEvent(): Generator {
// 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
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member Author

@dlech dlech Jan 23, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

// not technically a hotplug event.
yield* spawn(handleUsbConnectPybricks, pybricksDevices[0]);
}
}
Expand Down