DAPLink
DAPLink copied to clipboard
ARMmbed
Process out-of-order vfs sectors for Universal Hex in block format
Tested in a VM with macOS 13.1, which had the issue where files larger than 1 MB would be sent out-of-order:
- https://github.com/ARMmbed/DAPLink/issues/982#issuecomment-1314447196
13.0 also had an issue where the OS was trying to read back some metadata files it was writtin to the MICROBIT drive, and that caused issues when DAPLink sent back zeros. That metadata issue was fixed in 13.1, but the out-of-order was still present until 13.2, so 13.1 is the best version to test this.
The CI was failing because the kl27z_bl was running out of .text memory, as a build from the main branch only has around 320 bytes left from the 32 KBs allocated to the bootloaders. This affected the kl27z_microbit_bl as well, as it has even less free space, and would probably affect other bootloaders too.
- https://github.com/ARMmbed/DAPLink/actions/runs/13110451729/job/36573005874?pr=1092
So I've merged PR #1097 here to save enough flash to get these to builds successfully again.
- https://github.com/ARMmbed/DAPLink/pull/1097
I don't mind if we merge it all together in this PR, or merge PR #1097 first and then I rebase this PR afterwards, either way works for me.
I merged #1097, so you can rebase.
Could you have a look at https://github.com/mbrossard/DAPLink/tree/feature/vfs-tests? It's a way to unit test a part of the flashing logic. I think you should cherry-pick the vfs-tests commits and document how to download or build the different Universal Hex files.
Thanks @mathias-arm!
I've removed the PR https://github.com/ARMmbed/DAPLink/pull/1097 commit, rebased, and force pushed. I'll look into the vfs-tests once I find some time this week.
@mathias-arm just to let you know that I'm looking into this again. Currently looking at integrating and expanding the tests from https://github.com/mbrossard/DAPLink/tree/feature/vfs-tests .