You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Or with a device ID if multiple DFU devices are connected:
168
168
```shell
169
-
dfu-util -d 4c4b:4643 -D your-firmware.bin
169
+
dfu-util -d 4c4b:4643 -D your-firmware.bin -R
170
170
```
171
171
172
172
Find your device's VID:PID via `lsusb` on Linux or Device Manager (under "Universal Serial Bus devices") on Windows.
173
173
174
+
This will download the firmware binary onto the DFU partition of the flash and set a flag to tell embassy-boot at next boot that the firmware should be updated. Embassy-boot then proceeds to copy the data in the DFU partition into the ACTIVE partition by swapping page-wise. (This way the data in ACTIVE is swapped and can be rolled back). This process takes about 20 seconds for a ~120kB firmware, during which there is not LED activity.
@@ -211,3 +213,182 @@ Additionally the bootymcbootface bootloader has blinking codes using PIN_25 (RP2
211
213
| Successful DFU→ACTIVE copy; about to jump | 5 short blinks (50 ms) |
212
214
| Bootloader itself panicked (e.g. flash read error, invalid state partition) | Morse SOS (... --- ...), repeating |
213
215
216
+
---
217
+
218
+
## Split peripheral updates (dfu_split)
219
+
220
+
When using a split keyboard with separate microcontrollers for each half,
221
+
`dfu_split` lets you update the peripheral's firmware without a debug
222
+
probe or direct USB connection — the central acts as a relay.
223
+
224
+
In order for this to work, both, central and peripheral need to be flashed with an embassy-boot bootloader (e.g. bootymcbootface) and with a firmware that has `dfu_split` enabled. (See above on how to do that)
225
+
226
+
::: note
227
+
228
+
This feature currently only works for split keyboards that use UART (serial) as the interface between them. Split BLE and updates over the air wont work.
229
+
230
+
:::
231
+
232
+
### Feature flags
233
+
234
+
```toml title="Cargo.toml"
235
+
[dependencies]
236
+
rmk = { features = [ "dfu_rp", "split", "dfu_split"] } # or dfu_nrf instead of dfu_rp
237
+
```
238
+
239
+
`dfu_split` requires `dfu` (implied by `dfu_rp` / `dfu_nrf`) and `split`.
240
+
241
+
### Architecture
242
+
243
+
Two complementary paths are provided:
244
+
245
+
| Path | Mechanism | When to use |
246
+
|---|---|---|
247
+
|**Embedded**| The central includes the peripheral binary at compile time via `include_bytes!()` and flashes it automatically when the peripheral connects. | CI/CD, production, "flash-and-forget" |
248
+
|**Passthrough**|`dfu-util -a 1 -D peripheral.bin` sends the firmware through the central's USB DFU interface, which forwards it to the peripheral in real time. | Development, ad-hoc updates without connecting the peripheral to the host to flash |
249
+
250
+
Both paths split the firmware into 256-byte chunks and send them over the
251
+
split link as `FirmwareChunk` messages. The peripheral writes them to its
252
+
own DFU flash partition, verifies the CRC, and resets into the new image.
253
+
254
+
### Embedded firmware path
255
+
256
+
In order to embed the peripherals firmware into the centrals firmware, we need to tell the central during compilation where the binary of the peripheral is.
257
+
Note that this must be a .bin-file. You can create one using `cargo make bin`, see also the Makefile.toml in the examples.
258
+
259
+
::: tip
260
+
261
+
Use `dfu_lock` (see above) to lock the central against malicious flashing. `dfu_lock` will lock using the central as relay to flash a peripheral as well.
262
+
263
+
:::
264
+
265
+
import { Tab, Tabs, Rust, Toml } from'@theme'
266
+
267
+
<Tabs>
268
+
<Tablabel={<Toml />}>
269
+
270
+
Add a firmware field with the path to the peripherals firmware binary in the peripheral's section. This is a relative path starting from where the Cargo.toml is.
271
+
272
+
```toml title="keyboard.toml"
273
+
[[split.peripheral]]
274
+
rows = 2
275
+
cols = 1
276
+
firmware = "./peripheral.bin"
277
+
update_policy = "MatchHash"# optional
278
+
# update_policy = "force" to force a peripheral update every start of central
279
+
```
280
+
281
+
By default (`update_policy = "MatchHash"`, or when omitted) the central only updates the peripheral, when the firmware on the peripheral has a different checksum than the included firmware given by firmware.
282
+
283
+
The `#[rmk_central]` macro then generates the `set_firmware_update_data`
284
+
call automatically. When the field is absent the central relies on
285
+
passthrough only. (see below)
286
+
287
+
</Tab>
288
+
<Tablabel={<Rust />}>
289
+
290
+
Add this inside the main function of the central:
291
+
292
+
```rust title="central.rs"
293
+
// NOTE: CARGO_MANIFEST_DIR is where your Cargo.toml is
Where the first argument of `set_firmware_update_data` is the index of the peripheral. (The same as the first argument of `run_peripheral_manager`.)
306
+
307
+
When the `set_firmware_update_data()` is not called, the central relies on passthrough only.
308
+
309
+
</Tab>
310
+
</Tabs>
311
+
312
+
After flashing the central, it will ask the peripheral for its firmware checksum, the peripheral answers and if the checksum does not match with the checksum of the embedded peripheral firmware in the central, it will start flashing the embedded peripheral firmware onto the peripheral. The blink codes of the peripherals DFU LED (see above) are the same like during a normal DFU update. Additionally the centrals DFU LED will start blinking when sending the firmware to the peripheral. When UpdatePolicy::Force is given, the central skips this check and sends the firmware regardless of the checksum.
313
+
Likewise the peripheral will tell the central it’s firmware checksum proactively at every boot. So the firmware is still updated if the peripheral booted after the central. To avoid infinite loops of flashing and rebooting even when UpdatePolicy::Force is set, the central will not flash the firmware when the CRC is matching.
314
+
315
+
### Passthrough path
316
+
317
+
The passthrough pass works identically to the normal DFU flash (see above) — just select a
318
+
different alternate setting (`-a`). Up do four peripherals are supported.
319
+
320
+
```shell
321
+
# Flash peripheral 0
322
+
dfu-util -a 1 -D peripheral.bin
323
+
324
+
# Flash peripheral 1 (if you have a second peripheral)
325
+
dfu-util -a 2 -D peripheral2.bin
326
+
327
+
# Flash central
328
+
dfu-util -a 0 -D central.bin -R
329
+
```
330
+
331
+
::: warning
332
+
Do **not** use `-R` (reset) when flashing a peripheral. The peripheral
333
+
resets itself after the update. `-R` would reset the central.
334
+
:::
335
+
336
+
::: note
337
+
The index of the alternate setting (`-a`) is off by one due to technical reasons. So to flash the peripheral with index 0, you have to pass `-a 1`.
338
+
:::
339
+
340
+
### Peripheral firmware requirements
341
+
342
+
The peripheral must call `init_flash()` to partition its flash and `mark_booted()` so that the
343
+
bootloader does not revert the update. With `#[rmk_peripheral(id = …)]`
344
+
(TOML API) this is generated automatically when a `[dfu]` section is
345
+
present in `keyboard.toml`.
346
+
347
+
If you are using the Rust API on the peripheral, ensure you have this in your main function of the peripheral:
348
+
349
+
```rust
350
+
// for the different addresses for different chips see above
351
+
constFLASH_SIZE:u32=2*1024*1024;
352
+
constPAGE_SIZE:u32=4*1024;
353
+
constSTORAGE_SIZE:u32=128*1024;
354
+
constSTATE_OFFSET:u32=0x6000;
355
+
constSTATE_SIZE:u32=0x1000;
356
+
constACTIVE_OFFSET:u32=0x7000;
357
+
letremaining:u32=FLASH_SIZE-28*1024-STORAGE_SIZE;
358
+
letactive_size:u32= (remaining-PAGE_SIZE) /2;
359
+
letdfu_size:u32=active_size+PAGE_SIZE;
360
+
letdfu_offset:u32=ACTIVE_OFFSET+active_size;
361
+
letstorage_offset:u32=dfu_offset+dfu_size;
362
+
363
+
rmk::dfu::init_flash(
364
+
p.FLASH,
365
+
storage_offset,
366
+
STORAGE_SIZE,
367
+
STATE_OFFSET,
368
+
STATE_SIZE,
369
+
dfu_offset,
370
+
dfu_size,
371
+
);
372
+
373
+
// mark the firmware as booted otherwise the bootloader thinks it didn't and will revert to the old firmware
374
+
rmk::dfu::mark_booted();
375
+
376
+
// you can also set a DFU LED for the perpheral, it flashes during updates
Without `mark_booted()` embassy-boot will revert the update at next reboot, because it thinks the new firmware did not boot. (visible as three short flashes of the DFU LED when using bootymcbootface).
387
+
388
+
### Troubleshooting
389
+
390
+
| Symptom | Likely cause |
391
+
|---|---|
392
+
| Peripheral flashes 3 times after update | Firmware crashed or `mark_booted()` not called in the peripheral. Add `[dfu]` to `keyboard.toml` (using config) or call `rmk::dfu::mark_booted()` (using Rust). |
393
+
|`dfu-util -a 1` shows `dfuERROR` or hangs at 0% | Peripheral not connected or its firmware is built without the `dfu_split` feature. |
0 commit comments