Bootloader Recovery

Hi.

I was experimenting with running arduino-builder and bossac from the command line and for some reason was unable to upload using the command directly from the IDE. I then tried using an upstream version of bossa without realizing the one bundled with the IDE was specially patched. Unfortunately this appears to have bricked the device. The green power LED still comes on but it no longer shows up as a serial port and double tapping reset doesn't cause the red LED to start flashing.

I realize I was being reckless, but is there any hope for recovering this board?

Edit: To be clear, I can't follow the stickied instructions for boot loader recovery because the board no longer creates a serial port when plugged in. Double tapping reset does nothing. The command that appears to have killed it is

bossac -a -i -d --port=ttyACM0 -U -i -e -w build/vidor_template.ino.bin -R

chelmich,

Sorry to hear about your trouble; I'm usually one of the first to figure out how to brick something new. Ha!

I haven't used the bossac stuff (yet); but have you tried connecting via either J7 or J11? I would think it should be possible to at least put the 'bsp" back on if that has been erased.

Note you have to solder those yourself and figure out where pin 1 is (I may post a small DIY on all of this) and have the correct tools - USB Blaster for the FPGA and ARM JTAG (SW) debugger for the SAM; but that may be your alternative that can work.

Other than that or perhaps someone chiming in - I would think the support folks could help you also - maybe open a ticket if you don't get any replies that you can work with?

Good Luck,
John

Hi,

One note for FPGA JTAG connector. It's not standard connector and pinout. so you need to do adapter cable.

Not sure what is SAMD SWD connector pinout and can you use example stm discovery board for programming. It's from STM and about 10-20e.

From Microchip you can buy ATATMEL-ICE-PCBA. It's bare pcb of atmel ice debugger (about 50e + 20e for 10+6pin combo cable) Full atmel ice is about 120e and it was out of stock.

I think you can pretty easy figure out pinouts with multimeter.

Hi chelmich,

If you have another Arduino board which has 3.3v GPIOs, you may be able to use the following open-source SAMD programmer:

Programming an M0 using an Arduino

GitHub: GitHub - adafruit/Adafruit_DAP: port of free-DAP to standalone arduino

I have not tried it myself, but I hope it may help you.

Hi again,

Thank you for the helpful replies. I suspected one of the unpopulated headers would be usable for debug. Looking at the schematic as I understand it:

J7 is a 6-pin Cortex SWD port and connects only to the MCU
J11 is a 10-pin SAM JTAG (not ARM) that connects to both the FPGA and MCU

Is this correct? Assuming I had an Atmel ICE or some other debugger could I use either port to flash the bootloader?

tksm372:
If you have another Arduino board which has 3.3v GPIOs, you may be able to use the following open-source SAMD programmer:

Thanks for the suggestion. Unfortunately I don't have another 3.3v Arduino so I'll have to keep looking. Most debuggers seem to be as expensive as buying a new Vidor. :o

Assuming I get a debugger working I'm guessing my next step would be to somehow flash the clujtag-server.ino.bin described in the stickied post. Hopefully bossac works with whatever debugger I set up.

Thanks,
Charlie

Here is example how to do with raspberry pi
Open OCD for RaspberryPi

There they program at91samd21 with raspberry pi.

J7 is connector for programming SAMD21

If you have 5V arduino then you can use level shifters. if you use enough slow clock then you can use it.

Level shifter guide and schematics

Limba:
Here is example how to do with raspberry pi
Open OCD for RaspberryPi

Thanks, that sounds perfect. I'll try it out and report what happens.

Hi,
there is still the possibility you didn't clear the bootloader... please try doubletapping the button as soon as you attach the board to USB. the button is not a real reset so if you load a software that locks the processor the button won't do anything however unless you overwritten bootloader, it will still be executed and it''ll wait a bit before jumping to application and that's the small time window in which you can stay in bootloader by doubletapping

DarioPennisi:
Hi,
there is still the possibility you didn't clear the bootloader... please try doubletapping the button as soon as you attach the board to USB. the button is not a real reset so if you load a software that locks the processor the button won't do anything however unless you overwritten bootloader, it will still be executed and it''ll wait a bit before jumping to application and that's the small time window in which you can stay in bootloader by doubletapping

Thanks for the suggestion. Unfortunately I tried it multiple times and double tapped as quickly as I could but the LED stayed dark. That seems to indicate that the bootloader is nonfunctional. I'm almost set up to try the OpenOCD method. Do you know which is the correct file to flash? The bootloader recovery instructions assume you are already in a functional state over serial.

Mine bricked after uploading one of the sketches. No red LED. Very unstable.

Where is the Binary file for the bootloader?!?! No mkrvidor4000 folder in bootloaders and no xxx.bin on the GitHub repository. Unless the boot.ttf is a binary? Please help!!!

The six pin J7 on the schematic is for the SAMD21 SWDIO as stated but the ones I use for all of my SAMD boards has 10 pins. Right in between the io headers too. Looks like I am making a pogo jig. Something tells me this is going to happen again.

You can find the J7 orientation by using a multimeter on the ground and 3.3v pads.

Please help with the bootloader binary!!!

Hi,

In my PC, samd21_sam_ba_arduino_mkrvidor4000.bin is located here:
C:\Users(your_login_name)\AppData\Local\Arduino15\packages\arduino\hardware\samd_beta\1.6.25\bootloaders\mkrvidor4000

On GitHub, it is in the beta branch:
https://github.com/arduino/ArduinoCore-samd/tree/beta/bootloaders/mkrvidor4000

Thank you!. Will try it when I get home.

Worked perfect! Red LED on and I can see it in the IDE. Thanks!

Sorry for abandoning this thread for a while. I've been super busy and haven't had time to wrestle with the board.

I got an email about a post from jwestmoreland but it seems to be deleted. He asked about a possible USB 3.0 race condition or driver issue. Unfortunately I've tried both USB 3.0 and 2.0 on multiple machines. This issue also persists across power cycling my laptop. Plugging the board in does nothing in dmesg so I can only assume it's not communicating at all.

rrace001:
Worked perfect! Red LED on and I can see it in the IDE. Thanks!

Glad to hear it. Did you use OpenOCD? If so, would you mind posting your openocd.cfg? I seem to be having issues with mine.

I went with the Raspberry Pi SWD path that Limba suggested. I'm able to get some level of interaction with the board so I'm pretty sure my wires are good. However, flashing the bootloader always seems to fail. Does anyone have any idea what could be going wrong here? Apologies for the picture of a screen but I didn't take the time to get the output off the Pi.

734×937 152 KB

chelmich,

I think I must've accidentally deleted that post - sorry for any confusion.

I can try programming the bootloader via the programming interface - I have the Segger tools - I found this - I can't vouch for this outfit but could be a cheap alternative (I know zero about this programmer) - just looks like the price is right:

Note the actual Segger stuff is hightly recommended but not cheap (not as expensive as an Intel Quartus Prime Standard subscription) though.

Regards,
John W.
PS - Is the USB2/USB3 thing logged as an actual bug?
PPS - This link may be a better option for a lot of people here:

FWIW, I connected a Segger JTAG to the ATSAMD21G18A -

The connector for the Atmel JTAG:

MRK4K Upside Down:

===========================================

1 = =
===| 5 3 1 = =
| || || || = =
===| || || || = =
(USB) 6 4 2 = =

===========================================
J7 J11

1 - VTref
2 - SWDIO
3 - Reset(n)
4 - SWCLK
5 - GND
6 - NC

I have also attached a .bin file of the Atmel memory.

Regards,
John W.

MKR4000-AtmelSAMD21G18A.zip (32.3 KB)

tksm372:
Hi,

In my PC, samd21_sam_ba_arduino_mkrvidor4000.bin is located here:
C:\Users(your_login_name)\AppData\Local\Arduino15\packages\arduino\hardware\samd_beta\1.6.25\bootloaders\mkrvidor4000

On GitHub, it is in the beta branch:
https://github.com/arduino/ArduinoCore-samd/tree/beta/bootloaders/mkrvidor4000

It appears the .bin that's on github is an html file that has been converted to a .bin file -

That's at the top of that file- if you do a save-as.

Make sure you download from here:
https://github.com/arduino/ArduinoCore-samd/blob/beta/bootloaders/mkrvidor4000/samd21_sam_ba_arduino_mkrvidor4000.bin

Regards,
John W.

jwestmoreland:
It appears the .bin that's on github is an html file that has been converted to a .bin file -

Good catch. I checked an embarrassingly I had the wrong binary. Now I have the correct one but I'm still encountering issues with OpenOCD. It seems to be able to communicate fine but fails to write anything to flash. Here is my openocd.cfg and a log from trying to program it:

source [find interface/raspberrypi2-native.cfg]
transport select swd

set CHIPNAME at91samd21g18
source [find target/at91samdXX.cfg]

# gpio pins
bcm2835gpio_swd_nums 25 24
bcm2835gpio_trst_num 7
bcm2835gpio_srst_num 18

reset_config srst_nogate

adapter_nsrst_delay 100
adapter_nsrst_assert_width 100

init
targets
reset halt

# write bootloader
at91samd bootloader 0
program samd21_sam_ba.bin verify
at91samd bootloader 8192

reset
shutdown

BCM2835 GPIO config: tck = 11, tms = 25, tdi = 10, tdo = 9
BCM2835 GPIO nums: swclk = 11, swdio = 25
none separate
adapter speed: 400 kHz
cortex_m reset_config sysresetreq
BCM2835 GPIO nums: swclk = 25, swdio = 24
BCM2835 GPIO config: trst = 7
BCM2835 GPIO config: srst = 18
none separate
adapter_nsrst_delay: 100
adapter_nsrst_assert_width: 100
Info : BCM2835 GPIO JTAG/SWD bitbang driver
Info : JTAG and SWD modes enabled
Info : clock speed 400 kHz
Info : SWD DPIDR 0x0bc11477
Info : at91samd21g18.cpu: hardware has 4 breakpoints, 2 watchpoints
Info : Listening on port 3333 for gdb connections
    TargetName         Type       Endian TapName            State       
--  ------------------ ---------- ------ ------------------ ------------
 0* at91samd21g18.cpu  cortex_m   little at91samd21g18.cpu  halted
target halted due to debug-request, current mode: Thread 
xPSR: 0xf1000000 pc: 0xfffffffe msp: 0xfffffffc
target halted due to debug-request, current mode: Thread 
xPSR: 0xf1000000 pc: 0xfffffffe msp: 0xfffffffc
** Programming Started **
auto erase enabled
Info : SAMD MCU: SAMD21G18A (256KB Flash, 32KB RAM)
Error: SAMD: NVM programming error
Error: Failed to erase row containing 00000100
Error: SAMD: failed to erase sector 1 at 0x00000100
Error: failed erasing sectors 0 to 31
embedded:startup.tcl:480: Error: ** Programming Failed **
in procedure 'script' 
at file "embedded:startup.tcl", line 63
in procedure 'program' called at file "openocd.cfg", line 29
in procedure 'program_error' called at file "embedded:startup.tcl", line 539
at file "embedded:startup.tcl", line 480
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
shutdown command invoked

Based on the logs I suspect some issue with the NVM settings. I got the NVM user row with the command "at19samd nvmuserrow". The output was the following:

NVMUSERROW: 0xFFFFFC5DD8E00007

Would anyone with a functional board mind checking to compare? As far as I can tell, the way I'm invoking OpenOCD is identical to the way in the Arduino IDE scripts. I could potentially try that Adafruit SWD debugger although I would have to order it. I'm also open to any other suggestions.

Edit: I checked my flash dump against yours, John and unfortunately the section that should contain the bootloader (0x0 all the way up to 0x48F0) is filled entirely with ones. So this pretty much confirms that the bootloader got toasted somehow.

Edit 2: I checked the memory of the board using "mdw 0x804000 2" and checked the same location in your memory dump. They appear to be the same but with the endian-ness flipped. Specifically OpenOCD reported the following:

0x00804000: d8e00007 fffffc5d

I assume whatever tool you used to dump memory flipped the bytes. So that rules out issues with the NVM. Now I'm really confused as to what could be going wrong.

chelmich,

I used the tools that come with the Seggers - could be the classic PC byte swap that maybe those tools take care of automagically.

Just wondering - did you happen to install the bootloader update? I assume you have.

In the file I posted - that particular board hadn't been updated - and I found that by looking at what I posted here!

Just make sure you've done the latest bootloader update.

Regards,
John W.

John,

Thanks for the help with this. No, I didn't install the bootloader update before the board got bricked. Ironically that may have fixed the issues that I was fighting when it stopped working in the first place. I'm still struggling to understand why trying to flash a bootloader with OpenOCD doesn't work. The Arduino IDE runs a script that calls it and I'm matching their config exactly as far I can tell. I put in an order for the Adafruit SEGGER debugger to use instead of the Raspberry Pi. Hopefully that fixes things, but I'm not sure.

Charles