There wasn't power getting to target board so I plugged it into USB.
Now, Im getting:
Card initialized
fw.bin opened!
Connecting...
Starting debugger...
Adafruit Generic CMSIS-DAP Adapter 123456 v0.1 (S)
Enter Reset with Extension mode... Target prepare...
Found Target: SAM D21G18A (Rev D) Flash size: 262144 Flash pages: 4096
Erasing... done.
Programming... invalid response while writing the block
4
invalid response writing to reg 5 (count = 0, value = 4)
I.m a persistent cuss !
After running it and running it... it finally work 
Great news! I'm glad your persistence paid off.
Can someone tell me what this means from the procedure?
| Programmer | | Target | | - | - | | ----------- | |------- | | VCC | | +3V3 | | ----------- | |------- | | 10 | | SWDIO | | ----------- | |------- | | 9 | | SWCLK | | ----------- | |------- | | GND | | GND | | ----------- | |------- | | 11 | | RESETN | | ----------- | |------- |
Is there a PNG?
@pert
Like others before me in this topic I have a Nano 33 IOT that is not recognised when connected using USB and will not go into bootloader mode with a double tap on the reset button
I have Uno, classic Nano, ESP32 and ESP8266 boards but I am unclear whether any of these can be used to burn the bootloader to the Nano IOT
Way back in post #2 you said
but the example Adafruit DAP library > flash_from_SD does not appear in the file list when Uno or Nano is selected as the board
The file does exist but copying it into the IDE and compiling for a Uno does not work because there is not enough memory
Can you offer any suggestions ?
You'll find it under File > Examples > INCOMPATIBLE > Adafruit DAP library > samd21 > flash_from_SD. The reason for the "INCOMPATIBLE" is this in the library's metadata:
https://github.com/adafruit/Adafruit_DAP/blob/1.7.0/library.properties#L9
architectures=samd,esp32,esp8266
I get the same result. It might be that some of the recent development on the library (seems to be very active) has increased the memory usage, or maybe I only compiled it for Mega (My go-to AVR board for quick tests). You could try rolling back through versions of the library to see if one will compile.
I see they recently added support to the library for using ESP8266 and ESP32 as programmers, so you might give those a try.
I saw the ESP versions of the sketches and I will give them a go. The "flash_samd21_from_web_browser" example looks like the most likely candidate
I will report back when I have tried it
Success.
The Nano 33 IOT is alive and well
The "flash_samd21_from_web_browser" sketch using an ESP32 worked perfectly and so fast that I couldn't believe it
I am still in the dark as to what caused the problem in the first place
Thanks for the help
Great work! Even though it wasn't a fun experience for me to break my board, in the end I was glad that it gave me the motivation to learn about recovering the SAMD boards. I now feel much more free to experiment with those boards without fear of making an expensive mistake, even to the point of intentionally bricking boards so I can reproduce the conditions of the person I'm trying to help.
The mistake reported here of having the Nano 33 BLE board selected when uploading to a SAMD board is the most common.
The first time I bricked a SAMD board, it was when I ran a random bossac command from a forum user directly from the command line. I don't remember the exact details of what it was now. I'm more accustomed to the AVR Boards where there is pretty much nothing you can do via a serial upload that will require a programmer to fix.
I am sure that I didn't have the Nano 33 BLE board selected as I don't have it installed. It is more likely that I had an AVR board selected or just possibly an ESP32
However, now that I can recover the board, albeit with some inconvenience, it does not really matter but I might try to reproduce the problem
If you do manage to figure it out, I'd be interested to know.
I just bricked it again. I am still not sure of the exact sequence of events but I was doing much the same as I was the last time it happened trying to read serial data from a GPS
I have a GPS module powered from 3V3 and GND on the Nano. It works at 3V3, tested with an ESP32
Tx from the GPS is connected to Nano RX0.
Rx from the GPS is connected to TX1 on the Nano
Sketch as follows
void setup()
{
Serial.begin(115200);
while (!Serial);
Serial2.begin(115200); //GPS set up using u-centre
}
void loop()
{
if (Serial2.available())
{
Serial.write(Serial2.read());
}
}As far as I remember the sequence was :
With the serial connections not in place I can upload the sketch to the Nano but with them connected I get a Windows "last device not recognised" error. Double clicking the Nano reset button reconnects the Nano to the PC and it goes into bootloader mode (pulsing LED) as usual
However, having double clicked a couple of times there is no Windows connection sound, the pulsing LED is permanently off and no COM port is allocated and it remains the same with nothing connected
Once I have unbricked the Nano I will try it again but I will leave the DAP connections soldered in place this time 
Unbricked and back in business in bootloader mode
Bootloader reloaded in record time (I am getting good at it)
Conclusions - I cannot make the problem occur consistently but it seems to have something to do with changing COM ports and/or by trying to use the wrong port then changing back to teh correct one
I am off to reload the bootloader again which is no problem now that I have soldered pins to the DAP pads
EDIT : back in business in record time !