Arduino Forum

Products => MKR Boards => MKRVIDOR4000 => Topic started by: chelmich on Jan 29, 2019, 05:27 pm

Title: Bootloader Recovery
Post by: chelmich on Jan 29, 2019, 05:27 pm
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
Code: [Select]
bossac -a -i -d --port=ttyACM0 -U -i -e -w build/vidor_template.ino.bin -R
Title: Re: Bootloader Recovery
Post by: jwestmoreland on Jan 30, 2019, 03:02 am
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
Title: Re: Bootloader Recovery
Post by: Limba on Jan 30, 2019, 12:21 pm
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.
Title: Re: Bootloader Recovery
Post by: tksm372 on Jan 30, 2019, 05:23 pm
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
https://learn.adafruit.com/programming-an-m0-using-an-arduino

GitHub: https://github.com/adafruit/Adafruit_DAP

I have not tried it myself, but I hope it may help you.
Title: Re: Bootloader Recovery
Post by: chelmich on Jan 30, 2019, 06:15 pm
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?

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
Title: Re: Bootloader Recovery
Post by: Limba on Jan 30, 2019, 06:50 pm
Here is example how to do with raspberry pi
Open OCD for RaspberryPi (https://learn.adafruit.com/programming-microcontrollers-using-openocd-on-raspberry-pi/overview)

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 (https://learn.sparkfun.com/tutorials/bi-directional-logic-level-converter-hookup-guide/all)
Title: Re: Bootloader Recovery
Post by: chelmich on Jan 30, 2019, 08:26 pm
Here is example how to do with raspberry pi
Open OCD for RaspberryPi (https://learn.adafruit.com/programming-microcontrollers-using-openocd-on-raspberry-pi/overview)
Thanks, that sounds perfect. I'll try it out and report what happens.
Title: Re: Bootloader Recovery
Post by: DarioPennisi on Jan 31, 2019, 04:23 pm
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
Title: Re: Bootloader Recovery
Post by: chelmich on Feb 01, 2019, 01:15 am
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.
Title: Re: Bootloader Recovery
Post by: rrace001 on Feb 02, 2019, 04:21 am
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!!!
Title: Re: Bootloader Recovery
Post by: tksm372 on Feb 02, 2019, 04:41 am
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
Title: Re: Bootloader Recovery
Post by: rrace001 on Feb 02, 2019, 02:23 pm
Thank you!.  Will try it when I get home.
Title: Re: Bootloader Recovery
Post by: rrace001 on Feb 02, 2019, 11:50 pm
Worked perfect!  Red LED on and I can see it in the IDE.  Thanks!
Title: Re: Bootloader Recovery
Post by: chelmich on Feb 05, 2019, 02:58 am
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.

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.

(https://i.imgur.com/CW0l0It.jpg)
Title: Re: Bootloader Recovery
Post by: jwestmoreland on Feb 05, 2019, 05:12 am
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:

https://usa.banggood.com/The-J-link-OB-ARM-Emulator-Debugger-Programmer-Downloader-JLINK-Instead-Of-V8-SWD-p-1195533.html?gmcCountry=US&currency=USD&cur_warehouse=CN&createTmp=1&utm_source=googleshopping&utm_medium=cpc_bgcs&utm_content=zouzou&utm_campaign=pla-usg-ele-diy1-pc

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:
https://www.adafruit.com/product/3571?gclid=EAIaIQobChMIwfHshdyj4AIV0iCtBh2YagGKEAQYAyABEgKHUfD_BwE
Title: Re: Bootloader Recovery
Post by: jwestmoreland on Feb 05, 2019, 11:06 am
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.
               


Title: Re: Bootloader Recovery
Post by: jwestmoreland on Feb 05, 2019, 11:14 am
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 -

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="utf-8">
  <link rel="dns-prefetch" href="https://github.githubassets.com">
  <link rel="dns-prefetch" href="https://avatars0.githubusercontent.com">
  <link rel="dns-prefetch" href="https://avatars1.githubusercontent.com">
  <link rel="dns-prefetch" href="https://avatars2.githubusercontent.com">
  <link rel="dns-prefetch" href="https://avatars3.githubusercontent.com">
  <link rel="dns-prefetch" href="https://github-cloud.s3.amazonaws.com">
  <link rel="dns-prefetch" href="https://user-images.githubusercontent.com/">

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.
Title: Re: Bootloader Recovery
Post by: chelmich on Feb 07, 2019, 06:19 pm
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:

Code: [Select]

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

Code: [Select]

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.
Title: Re: Bootloader Recovery
Post by: jwestmoreland on Feb 09, 2019, 07:21 am
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.
Title: Re: Bootloader Recovery
Post by: chelmich on Feb 09, 2019, 04:26 pm
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
Title: Re: Bootloader Recovery
Post by: rrace001 on Feb 10, 2019, 01:50 am
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 have never used OpenOCD. I use the Segger JLink edu mini I got from Adafruit.  Never had a problem with it. It is almost indestructible and it only costs $20.  I use the Segger JLinkExe command line tool for lInux that I downloaded from the Segger website.  Very easy to use. Highly recommend it. 
Title: Re: Bootloader Recovery
Post by: jwestmoreland on Feb 10, 2019, 12:46 pm
Charles,

Have you tried this:

http://downloads.arduino.cc/tools/VidorFPGARecovery.zip

I ran through it - works OK - had a couple of boards that appeared the NINA-W102 was unresponsive.
Ran that and I could talk to the NINA's again - of course this could be that serial port issue as well.

Give that a try if you haven't already.

Regards,
John W.
Title: Re: Bootloader Recovery
Post by: jwestmoreland on Feb 19, 2019, 03:18 am
Charles,

Did you get your Segger I/F?

Have you unbricked your board?

Regards,
John
Title: Re: Bootloader Recovery
Post by: chelmich on Feb 19, 2019, 03:40 am
John,

Not yet. I ordered a Segger debugger but forgot to include the breakout board, so I'll have to wait a bit longer. As far as the FPGARecovery procedure you mentioned I can't use it because it relies on getting the board into bootloader mode by double tapping the reset. Because my bootloader appears to be nonexistent that isn't an option. So for now the board is still bricked. I appreciate the help though.

Charles
Title: Re: Bootloader Recovery
Post by: jwestmoreland on Feb 19, 2019, 04:17 am
Charles,

I assume you've soldered down the 6-pin surface mount header you need for the ARM, correct?

I have that P/N - but the schematic has those also - note Arrow has some really good deals right now - no shipping even on small orders - not sure if that applies to overseas and/or AL or HI.

I've actually bought more stuff from Arrow lately than Digikey or Mouser (I still love Digikey and Mouser) - Arrow has just got aggressive - and next day - no extra charge in a lot of cases - note this could apply only to continental US - not 100% sure.

Those in Europe could have a similar deal since Arrow is worldwide - not sure about places like Japan though.  Maybe in Japan they have plenty of DIY shops.

Regards,
John
PS - I don't work for Arrow nor do I get paid or compensated for any of the above comments. Just trying to pass on the 'news' to fellow DIYers.
Title: Re: Bootloader Recovery
Post by: chelmich on Feb 19, 2019, 04:28 am
Thanks for the heads up.

And yeah, I soldered some wires onto the 6-pin header since I don't have a 0.5 pitch surface mount header lying around. It mostly worked with the Raspberry Pi but like I posted before I was having issues flashing anything. Perhaps I was doing something wrong with OpenOCD but I don't think so. Either way, hopefully the Segger fixes it.
Title: Re: Bootloader Recovery
Post by: jwestmoreland on Feb 19, 2019, 09:06 am
Charles,

Actually - the header for the ARM is 0.1" pitch.  For the FPGA it is 0.05".  The ARM's is 6 pins and the USB Blaster I/F is 10 pins.

Regards,
John
Title: Re: Bootloader Recovery
Post by: chelmich on Feb 19, 2019, 06:04 pm
My bad, I was thinking of the debugger. The cable it has uses a 0.05 pitch which is why I need the breakout board. I did successfully solder onto the ARM header though. I'm pretty positive of this because I was able to read data off the SAMD through OpenOCD.

I'll be sure to keep this thread updated when I try the Segger.