Hi there,
I think I bricked my audrino mkr1500. I accidentally loaded a test firmware on it and since then I am unable to see that in the device manager when I connect it. The LED lights up after connecting. I do not have another audrino mkr1500 to load bootloader from it. Can I use audrino UNO or mkr1400 to reflash it?
Any help is appreciated.
The tricky thing about the boards with native USB functionality like your MKR NB 1500 is that the USB code that creates the CDC serial port is running on the same microcontroller as your sketch. This means your sketch code can break the USB code, or stop it from running. When that happens, it no longer presents a port.
That makes it so you can't upload normally any more. However, the situation is really not so bad because there is an independent program called the bootloader in a separate section of memory from your sketch, and that program has its own USB CDC code. So even if the sketch is completely broken, you only need to activate the bootloader and you will get a port back and be able to upload.
Fortunately, there is an easy way to recover from this situation:
The upload should now finish successfully. After this, you should be able to go back to doing normal uploads without needing to press the reset button. If you still need to do the reset trick to do uploads after this, the problem may be caused by your code. You can verify this by uploading a simple sketch like File > Examples > 01.Basics > BareMinimum.
I'm not sure about the Uno, but you can use a MKR GSM 1400. However, let's hope the double reset technique will be all you need.
If it turns out that it is necessary to burn the bootloader to recover your board, I'm happy to provide detailed instructions for that procedure.
Thanks a ton @pert !! Double clicking the reset button did actually resolve the issue.
You're welcome. I'm glad to hear it's working now. Enjoy!
Per
I think shoot the boatloader..;=( After the setup described by pert in Unable to load any sketch in a MKRWAN1300 - #3 by gigi130358
I had the following output:
2:31.902 -> Card initialized
15:42:31.902 -> Connecting...
15:42:32.011 -> Adafruit Generic CMSIS-DAP Adapter 123456 v0.1 (S)
15:42:32.011 ->
Enter Reset with Extension mode...
15:42:32.158 -> Target prepare...
15:42:32.158 -> invalid response writing to reg 0 (count = 0, value = 7)
Ergo: Card ok, firmware ok, connection ok, writing the bootloader not ok.
Any hints? Thx
Here's the answer to my question (i was blindly following pert ;=):
There is a special section for all MKR Boards in the examples!
The connections are a little different:
17:58:48.765 -> This sketch is for updating Arduino MKR and some other ATSAMD21G18, 32-Bit ARM Cortex M0+ boards
17:58:48.765 ->
17:58:48.765 -> The Arduino board should have these connections:
17:58:48.765 -> SWD pad SWDCLCK connected to programmer board pin 2
17:58:48.765 -> SWD pad SWDIO connected to programmer board pin 1
17:58:48.765 -> SWD pad SWDRESET or RESET header pin connected to programmer board pin 0
17:58:48.765 -> Vcc (3.3V) pins should be connected between programmer and target boards
17:58:48.765 -> GND pins should be connected between programmer and target boards
So: Flash MKR Bootloaders: Use examples/flash_MKR_bootloaders.ino.
A little hint: "no line ending" has to be enabled to make the board choice work. With "Both NL & CR" it's not working.
Worked like a breeze!
Thanks for taking the time to share your findings @intstarep! I wrote those instructions at a time before the MKR-specific example was added. I did notice there had been some general enhancements made to the Adafruit DAP library since that time, but I didn't have time to take a close look so I wasn't aware of this wonderful enhancement. I'll be sure to update my instructions accordingly before the next time I share them.
An unfortunate aspect of using the forum to share knowledge is that we end up with many variations of the same information scattered through the immense jumbled trove of brain treasure that is the Arduino forum. The culture here is even such that there are taboos, prohibitions, and even technical mechanisms that prevent maintaining a single canonical copy of a piece of information. It works well enough in the end, but it is frustrating when it means that there will likely always be people finding outdated copies of the information even after we have moved forward.
On the upside, in this particular case I do think that my existing instructions should still be valid, if far less convenient than the new approach. I'm not sure why the "flash_from_SD" sketch didn't work for you.
I totally agree. This case is a perfect example. I bricked the bootloader some hours ago and find your topic while googleing for a remedy. Then i followed your instructions and failed. I found the Adafruit enhancements and noticed that they did not work in the Arduino IDE with CR and NL in the serial monitor. So i wrote a little comment in github.
Six (6!) minutes later THE lady Ada asked me to make a PR. Now your input...it's a fantastic example for this open source model...
Your instructions enriched with the new Adafruit lib / MKR section is maybe worth a little guide on the arduino website? Thx for your contributions!
The greatest thing is that I'm not even surprised to hear that, having observed quite a few examples of this level of responsiveness over the years, even in some cases during New York City night time on weekends.
This topic was automatically closed 120 days after the last reply. New replies are no longer allowed.