-
Notifications
You must be signed in to change notification settings - Fork 39
EV3 USB hacks #2356
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
EV3 USB hacks #2356
Changes from all commits
24dcfab
158476f
e001642
7a6a249
37de6a5
fcb0286
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change | ||||
|---|---|---|---|---|---|---|
|
|
@@ -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). | ||||||
| return 0; | ||||||
| } | ||||||
|
|
||||||
| return maxChunkSize - (remainder % maxChunkSize); | ||||||
| } | ||||||
|
|
||||||
| /** | ||||||
| * Loads Pybricks firmware from a .zip file. | ||||||
| * | ||||||
|
|
@@ -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); | ||||||
|
|
@@ -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( | ||||||
|
|
@@ -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 | ||||||
|
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Suggested change
|
||||||
|
|
||||||
| 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); | ||||||
|
|
@@ -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); | ||||||
|
|
||||||
|
|
||||||
| 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'; | ||
|
|
@@ -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 | ||
|
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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.
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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 |
||
| // 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) { | ||
|
|
@@ -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. | ||
|
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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.
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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 | ||
|
|
@@ -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 | ||
|
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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?
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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).
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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]); | ||
| } | ||
| } | ||
|
|
||
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
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.There was a problem hiding this comment.
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.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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 :)