search

shumatech / BOSSA

BOSSA is a flash programming utility for Atmel's SAM family of flash-based ARM microcontrollers. The motivation behind BOSSA is to create a simple, easy-to-use, open source utility to replace Atmel's SAM-BA software. BOSSA is an acronym for Basic Open Source SAM-BA Application to reflect that goal.
http://www.shumatech.com/web/products/bossa
BSD 3-Clause "New" or "Revised" License
362 stars 251 forks source link

erase option wipes SAMD21 protected bootloader, fuses #99

Open mattvenn opened 5 years ago

mattvenn commented 5 years ago

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:

image

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:

image

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.

mattvenn commented 5 years ago

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.

paulalting commented 4 years ago

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.

elfmimi commented 4 years ago

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

dimostant commented 5 months ago

Hello everyone, I have an issue and i thought maybe you could help. Excuse me if the answer is on the above post and i just dont see it.

I have a feather M0 (non-express) board. I was trying to install circuitpy. In order to do this i had to install using bossac a (probably) uf2 bootloader to it from : https://github.com/adafruit/uf2-samdx1/releases. I am not really sure which one but it was a .bin file.

I tried using bossa GUI but i did the mistake mentioned above, i clicked erase all and forgot the offset. Since then the feather has its red led rapidly blinking and its unrecognised by the COM.

It only connects if i double click, but only for a brief second then it disconnects, making it impossible to use bossac to it. I have flashed the original hex bootloader using OpenOCD on raspberry PI zero W through SWD. Im back at the blinking led part.

What can i do?I appreciate all your help and thank you .

elfmimi commented 5 months ago

@dimostant That blinking behavior indicates that you have successfully wiped fuse bits. effectively enabling WDT and force resetting the bootloader periodically. Try flashing bootloader-feather_m0-v3.15.0.bin using OpenOCD. which has a feature to automatically fix wiped fuse bits.

dimostant commented 5 months ago

I have to thank you so much! i solved my problem, which was to add circuit python!

However I should note some things because for someone trying to return to the original Arduino IDE its gonna be an issue. I tried to install the binary you provided however as I mentioned only .hex files were running in the board ( and uf2's but they were buggy, at least the ones I tried ).

So what I did was convert it to .hex using :

objcopy -I binary -O ihex bootloader-feather_m0-v3.15.0.bin bootloader-feather_m0-v3.15.0.hex

in the raspberry. ( I moved the .bin file from windows to raspberry using winscp through ssh).

After that it didnt work so I used the .hex that was found in :

https://learn.adafruit.com/proper-step-debugging-atsamd21-arduino-zero-m0/restoring-bootloader

,the featherm0bootloader_160305.zip button.

I burned that with opeocd successfully and now the bootloader was working but it had a weird artifact. In arduino IDE the feather m0 was show in two different COMS at the same time and ofc when I was trying to upload a sketch it wouldn't work. I pushed the red button twice and again the bootloader would appear for some milliseconds and then disappear again. Indicating the only difference ,since before using the new binary, being that it was showing up on the arduino IDE.

However that there was a 3rd COM when I pushed the red button twice ,to which I did the bossac i tried the first time , using the latest circuitpython for featherm0 basic binary. And Voilà. Circuit python runs properly.

How ever i dont know if reverting back to the original binary or hex will have the board working properly for the arduino IDE. I need the board for a project now, but i will try at my first convenience.

Thank you for your help again and I hope it helped in case someone needs this.