Does the m1/m2 expose a serial port on the USB-C connector? I haven't seen that outside of mobile phones that require special debugging jigs (most requiring a secret resistor values between various pins to turn it on).
This actually looks like something I needed to build for some low-level bootloader work, and I had exactly the same sort of poor failure rate for my USB switches. I chalked it up to my inexperience in board design at the time, but I guess the board production house might have just been pretty poor.
See https://github.com/AsahiLinux/docs/wiki/HW%3AUSB-PD - some of the USB-C ports respond to USB PD Vendor-Defined Messages to trigger a bunch of debug features, including rebooting the SoC or configuring one of the internal UARTs to output to two pins on the USB-C connector.
If an update goes really wrong (ie. battery died in middle of an update), the Mac may need to go into DFU mode and get a firmware write over USB.
I don't know if this is the actual format the firmware update uses, but the ports listed in the official documents match the "special" ports in the wiki there.
Honestly, with flash so cheap these days, why isn't the firmware structured as two "partitions", each with a timestamp and checksum, and a small stub that
(1) is never overwritten
(2) is capable of accepting firmware updates over serial connection / TFTP / etc.
(3) checksums the newest firmware "partition" runs it if the checksum checks out
(4) falls back to the older "partition" of firmware if the checksum indicates corruption and/or partial update
Having had to TFTP-update several (and in one case exacto-knife jump two pins on the flash) WRT-54G firmware updates before I learned that the WRT-54G firmware update had issues with FireFox's HTTP POST implementation, I really wish firmware updates were more robust. A firmware update also bricked an early FitBit of mine.
If a sufficiently robust integrity check is used, then an update failure is just a no-op, not a bricked (or even reduced capability) device, no?
Now, pushing a bad firmware version is another story, and impossible to prevent unless the firmware updater contains some impossibly complex static analysis tools to formally verify some set of correctness properties of the incoming update.
This is far more sophisticated than the protocol I was working with, cool!
In my design I needed to do the a similar thing -- physically switch the USB2.0 lines between USB and raw serial. Using the pico for a USB serial gadget is smart. I used a USB/serial adapter for my project and it was a PITA.
More info in the README: https://git.kernel.org/pub/scm/linux/kernel/git/maz/cs-hw.gi...
This actually looks like something I needed to build for some low-level bootloader work, and I had exactly the same sort of poor failure rate for my USB switches. I chalked it up to my inexperience in board design at the time, but I guess the board production house might have just been pretty poor.
EDIT: I used a TS3USB30ERSWR in my design.