Skip to content
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

Add support for UF2 format #971

Open
wants to merge 1 commit into
base: develop
Choose a base branch
from
Open

Conversation

xingrz
Copy link

@xingrz xingrz commented Jul 22, 2022

This PR implemented the drag-n-drop support for UF2, which is mentioned in #745 (comment).

@mathias-arm mathias-arm self-requested a review July 22, 2022 14:11
@mbrossard
Copy link
Contributor

This is a really exciting addition.

What tools for generating UF2 files have you tested this patch with?

@xingrz
Copy link
Author

xingrz commented Oct 2, 2022

What tools for generating UF2 files have you tested this patch with?

Tested with UF2 built by Zephyr, which internally uses uf2conf.py

@mbrossard
Copy link
Contributor

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);
Copy link
Collaborator

Choose a reason for hiding this comment

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

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)) {
Copy link
Collaborator

Choose a reason for hiding this comment

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

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants