shumatech
erase option wipes SAMD21 protected bootloader, fuses
built from git source at 8202074d53ba666a7bbe9def780a9a9f78a4b140 on Linux
I am using SAMD21, I have a modified Arduino Zero bootloader in the first 8k, with BOOTPROT fuse set to cover first 8k:
0xFFFFFC5DD8E0C78A
After starting the bootloader, I run the bossa GUI.
If I set the 'erase all' option (no offset) and click 'write' then sometimes I get:
After the fail, bootloader is corrupted and all fuses are set to 1: NVMUSERROW: 0xFFFFFFFFFFFFFFFF
I can recover by re-flashing bootloader and re-setting fuses with openocd and Atmel ICE programmer. But the reserved bits of the fuses are now always set to 1 and can't be changed: NVMUSERROW: 0xFFFFFE5DD9FEC78A
I can repeat the exact same steps, but this time the write succeeds:
the bootloader and fuses remain intact.
It's difficult to say, but it seems maybe 1 in 20 times this will happen. Obviously I'd like to prevent it!
I don't know enough about SAM-BA - is it possible for SAM-BA to change fuses? I thought not. I'm definitely open to the idea that this is a problem with the bootloader, perhaps overwriting itself and the fuses. But it is very close to the official Arduino Zero bootloader.
I've done some more investigation, and I think it must either be a chip problem or the implementation of SAM-BA on the Arduino Zero bootloader. I've opened an issue over there: https://github.com/arduino/ArduinoCore-samd/issues/417
And also talking to Microchip.
With no value set for "General Options: Flash Offset", I have effectively bricked a new SAMD21 development board for a project.
Having never had to set a value in earlier versions for this, I have found this out all tool late only to find here what the went wrong. No device found in /dev anymore for this device, no matter what I do.
It should be that some default value be set for Flash Offset or to at least warn a user that if no offset is set and that if any boot-loader is installed, that it is at risk of being over written ?
I don't have a JTag or SWD system to push the boot-loader back in, so am now stuck until I new board is shipped to me.
Also, the build instructions under GNU/Linux should state the necessary dependencies, libwxgtk3.0-dev and libreadline-dev. I had to search why the build was not happy. Please include this in the instructions for building. Being explicit is far better than making assumptions, from a users point of view.
I have solved this mystery.
First of all, you can reproduce this behavior by executing the following command.
bossac -t0 -e
or
bossac -t1 -e
Depending on current state. Doing both is just what it takes to make sure it takes effect.
What's going on? With -o omited, -e issues "X00000000#" command to "erase all". The bootloader starts to erase all of the flash memory range starting literally from address 0. The bootloader itself is safe at this point. Because it is protected by BOOTPROT . But ERROR bit in NVMCTRL->INTFLAG register gets set. After this, ERROR bit won't be reset until the execution reaches the following lines. https://github.com/shumatech/BOSSA/blob/2d2daa1c061965d61e1a8fa4b045ce87912670b0/src/D2xNvmFlash.cpp#L228-L230 The NVM_CMD_EAR command will be executed with ERROR bit still being set. And eventually an exception is thrown and the execution stops just after erasing the NVM User Row (or the fuses if you like) . https://github.com/shumatech/BOSSA/blob/2d2daa1c061965d61e1a8fa4b045ce87912670b0/src/D2xNvmFlash.cpp#L330-L335
