Conversation
|
This is a really exciting addition. What tools for generating UF2 files have you tested this patch with? |
Tested with UF2 built by Zephyr, which internally uses uf2conf.py |
|
I started adding UF2 target binaries for the Zephyr DAPLink Validation binaries (mbrossard/zdv@1d5689a). Zephyr's build system insists on having a Family ID. It brings some interesting questions how DAPLink should handle Family ID. |
| return status; | ||
| } | ||
|
|
||
| status = flash_decoder_write(start_addr + block->targetAddr, block->data, block->payloadSize); |
There was a problem hiding this comment.
The start_addr + block->targetAddr part does not seem to match the UF2 specification in the sense that block->targetAddr is supposed to be an address, not an offset (from start_addr). It probably works in many case where start_addr is 0.
The code should verify that block->targetAddr is within flash bounds, and probably strictly increasing.
| const flash_intf_t *flash_intf; | ||
| const UF2_Block *block; | ||
|
|
||
| if (1 != validate_uf2block(data, size)) { |
There was a problem hiding this comment.
This code assumes the calls to write_uf2() are one sector (512 bytes) long. Looking at file_data_handler() in source/daplink/drag-n-drop/vfs_manager.c, it looks like it could be multiple sectors (though I am not sure this can actually happen).
There is also the CMSIS-DAP / WebUSB commands (see source/daplink/cmsis-dap/DAP_vendor.c) for flashing files, because it works over the HID endpoint will (once framing has been removed) write about 40 bytes at a time.
We might need a buffer (the shared_state_t variant from hex files already has a 256 bytes buffer).
3 participants
This PR implemented the drag-n-drop support for UF2, which is mentioned in #745 (comment).