MKRZero / SamD bootloader which can flash from SD card

I have a custom board which is similar to an Arduino MKRZero. In our application, it would be useful if we could have our users update the code on the board by inserting an SD card containing the hex file. Is there a bootloader that supports this functionality (while still supporting the normal usb programming).

the SDU library is bundled with the SAMD core. see the example.
to get the bin file (not hex), use "Export compiled binary" from the Sketch menu. it will put the .bin next to the ino file

1 Like

Thanks! This seems to solve half of my problem ( how to create the hex file). But is there a boot loader I can install in my boards which will flash the hex file it finds in the sd card?

the SDU library adds a second stage SD bootloader before the sketch

1 Like

I've made progress. I looked at the SDU library and it checks for #defines for supported boards. Since I have a custom board, I modified sdu.cpp to make it compile 'as-if' my board is an arduino MKRZero. My board doesn't completely match the MKRZero, its closer to a Zero but the SD card pins match the MKRZero. This appeared to partially work: when I put a compiled sketch on the SD card and power cycled, my board did not start running its code but when I looked at the SD card, the bin file was removed so I think SDU did try to flash. However, now my board doesn't seem to work: I tried re-burning the bootloader with the SAM-ICE which claims to be successful (verifies, had no errors) but the computer does not detect my board any longer so I can't download sketches using the arduino IDE any more. Basically after trying to use SDU once, my board appears to have stopped working.

you can use double reset to activate the bootloader if port is not visible. the LED should pulsate.

did you convert the compiled SDUBoot sketch to the array in .h for the SDU library?

1 Like

Ok double-reset and now I can download sketches again (with standard bootloader and a sketch without SDU). In my test that failed, I tried just including SDU.h in my current project, I didn't try with a minimal sketch. I'm not sure what you're asking when you say "did you convert the compiled SDUBoot sketch to the array..." Thanks so much for your help, I feel like I'm very close to a complete solution.

Ok its fully working now. The problem I had on the first try was my sketch was using too much RAM and adding SDU must have pushed it over some limit. I've now tested small test sketches as well as my fully functional (but slightly reduced size) sketch and SDU works great. In our use case, there would be a small benefit if SDU was in the actual bootloader rather than in the sketch, do you know if that is possible? It looks like its around 12K so maybe its too big to squeeze into a bootloader?

why do you want it as bootloader?
the SDU should not take RAM when your sketch runs.

We anticipate users possibly sharing .bin files with each other with most of them not actually knowing how to use the IDE, etc. If the SDU functionality is in the actual bootloader they can always recover from a bad bin file on their board by inserting an SD card with a known working bin file. The way it currently works, they could get themselves stuck to the point where they have to install the IDE, our libraries, our board config and learn how to download a sketch.

Its an edge case and I don't know for sure how much trouble it will cause us but it would be nice if we could close that loophole.

why would the sketch stop working? it is as safe as the bootloader in the flash memory

Our 'normal' users would have no way of messing up the bootloader. But they would be constantly overwriting their sketch. Someone could use a bin file that didn't have the SDU code in it and then not be able to update their device. If we include the SDU code in our library, that would be extremely unlikely though.

the SDU part of the sketch is not overwritten while loading the bin from the SD card. a sketch without SDU would just not work when loaded as bin from the SD card, because a part of the size of the SDU is skipped at the beginning of the bin.

even then a bin with SDU would still load and run

Oh I didn't realize those details, wow this is a complete solution and extremely simple to implement. Thanks again for the help.

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.