#Yes, this is definitely familiar! See <

1 messages · Page 1 of 1 (latest)

spark fern
#

Much appreciated, I will! I did actually realise that we needed to update our bootloaders (they were on 3.4.x) and rebuilt to 3.16.x recently but I found that we were getting some other weirdness (on half of them🤷 ) and reverted back to 3.4.x for the near term. I still don't understand all these new-fangled uf2 bootloader options that are in 3.16.x so if there are any hints on setting the build up to result in a really stable bootloader with double-tap and accessible by BOSSA, I'd love to hear what you go for. It looks like HID and web interfaces are the new hotness but that makes me pretty wary!

indigo imp
#

they are old hotness. It was not clear to me you were using our bootloader.

spark fern
#

Yes, flash bytes. Memory dumped and just get a bunch of zeroes before everything else looks the same.

indigo imp
#

Note that there is a problem with these SAMD UF2 bootloaders that showed up on Chromebooks on and off, and just showed up for me on Ubuntu 26.04 (which I just moved to). It is provoked by fwupd on a Linux box trying to do a unimplemented ATA IDENTIFY command via USB MSC. I happen to be debugging the problem this morning.

spark fern
#

Aha, thank you. I don't think we are going to run into that but I will track it.

indigo imp
#

you can recompile the bootloader without those extra options. look in uf2.h to turn them off

#

what is the "other weirdness" you saw?

spark fern
#

I haven't got my build VM spun up atm but I will check what flags we had. So the weirdness that we weren't keen on about our 3.16.x. bootloader was in the application (strange, I know but reverting bootloader fixed it). We were using a GPIO PB08 to perform reset control over another IC which is also connected to SAMD51 over UART and 2 other GPIOS as interrupts in either direction. The other IC has a high impedance reset pin and that line has a 10k pullup to 3.3V that both ICs are using for logic level and main supply. When we set PB08 pinMode(OUTPUT) and digitalWrite(LOW) for a few ms to reset the other IC, the SAMD51 would just enter a bootloop. Removing the other IC and the pullup allowed PB08 to operate normally. Reverting to the 3.4.x bootloader allowed it to work as intended.

indigo imp
#

i have to be away for a while but will study this when I return.

indigo imp
spark fern
#

We have our own version of the bootloader build but haven't changed much that I can recall e.g. boot LED pin (not PB08!). Yes, Arduino for build. I'm trying to get hold of which versions we're using but relatively recent IIRC for core etc.

#

I will boot up the bootloader build VM and dig out some config details to see if there are any noticeable differences from ItsyBitsy. I'm pretty sure I changed as little as possible to avoid trouble!

spark fern
#

Hi @indigo imp I'm getting back into this. I think some of what confused me by you saying "the old hotness" made me think you were using webserial and HID instead of UF2 MSC these days.

Looking at https://github.com/adafruit/uf2-samdx1/blob/master/inc/uf2.h where most of the config for build options happens, it seems that your default is to have WebUSB and HID enabled. I don't think I need these two as we are planning on using BOSSA only.

Do you know if we keep #define USE_SINGLE_RESET 1 does the bootloader need help to get into the application? Is this flag describing the default I would see in the ItsyBitsy experience where a single reset from the application should result in the application eventually being run again (perhaps after the bootloader has checked the reset cause and exited)? I am confused about what the expected behaviour might be and by leaving it set have I made problems for myself when trying to update via a USB mux!

These are my current flags/defines attached. Thanks for talking to me about this.

📎 current_defines.txt
indigo imp
#

I just released v4.0.0, which fixes a problem on ChromeOS and more recent Linux platforms (those which use fwupd 2.x.x).

spark fern
#

Thanks Dan. I have turned HID/WEBUSB off. We will give it a whirl and update to 4.0.0 (congrats and thank you!) after we confirm the USE_SINGLE_RESET 0 works for us.

Btw, I saw some recent stuff in the uf2 repo that makes me think BOD33 is now implemented, whereas when the power-down flash-wiping issues seemed to walk back on the bootloader implementing the BOD33 and the user needing to set it in application code. What's your latest understanding on BOD33 in the bootloader?

indigo imp
#

USE_SINGLE_RESET shouldn't make any difference, but maybe somehow it is for you. It only enables a capability which the application can turn on; it doesn't change default behavior.