Carlos Pereira Atencio

The original issue in macOS 15.0 was also fixed in 15.3.1.

> 2. UF2 FamilyID corresponds to an MCU family or specific MCU variants, but it doesn't quite match the Mbed/DAPLink Board ID > * 2.1) We could try to allocate...

> I agree with your "Won't Implement" items and I don't think that we should work on the "Could implement" item until it is an actual requirement. Sounds good 👍...

Thanks everyone! > I would suggest doing both 2.1 and 2.3 in the bootloader, that is I'm happy with `0xDA91_xxxx` range Yeah, I agree this sounds like the best option....

I've pushed to my fork the current WIP branch, as it might help illustrate my current approach. Consider this branch ongoin and untested: - https://github.com/microbit-carlos/DAPLink/compare/ignore-delete-soon...feature/uf2-ooo The DAPLink Interface will flash...

> If it's not too much bother, it would be nice to support this family-latching (and treat no family as family 0 or something), for better user experience. Yeah, I...

Yeah, if you prefer using a tag that sounds good too. Hopefully the inlined `daplink_is_bootloader()` compiles out the checks in the interface builds. > either we define two tags with...

Ah, I see what you meant now, thanks for the clarification! I'm a bit worried about the interface updating the bootloader on the fly, in case we don't receive all...

No, this is present in live and beta.

Live have similar times as beta, so not a regression.