Pretty comfortable that the 4 connections are solid and it reacts differently with swdi9 & swclk disconnected.
C:\XIAO_bootloader>c:\OpenOCD\bin\openocd -f XIAO_openocd.cfg
Open On-Chip Debugger 0.11.0 (2021-11-18) [https://github.com/sysprogs/openocd]
Licensed under GNU GPL v2
libusb1 09e75e98b4d9ea7909e8837b7a3f00dda4589dc3
For bug reports, read http://openocd.org/doc/doxygen/bugs.html
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
DEPRECATED! use ‘adapter srst delay’ not ‘adapter_nsrst_delay’
DEPRECATED! use ‘adapter srst pulse_width’ not ‘adapter_nsrst_assert_width’
Info : clock speed 400 kHz
Info : STLINK V2J17S4 (API v2) VID:PID 0483:3748
Info : Target voltage: 3.110828
Error: init mode failed (unable to connect to the target)
Don’t have ST_Link Utility running due to missing .dll files. Is STM32 ST-Link the correct program ?
Looks like the same place I got it from except my version was in English. I’ll uninstall and reinstall. Same version number. Same problem. I found & installed the 2 dll files it said it needed then there is a message saying it can’t start correctly. This is a Win10 machine.
Yes, that’s fine. Tells me old st-link fw. I think I updated FW on the ST-Link.
C:\XIAO_bootloader>C:\OpenOCD\bin\openocd -f XIAO_openocd.cfg
Open On-Chip Debugger 0.11.0 (2021-11-18) [https://github.com/sysprogs/openocd]
Licensed under GNU GPL v2
libusb1 09e75e98b4d9ea7909e8837b7a3f00dda4589dc3
For bug reports, read http://openocd.org/doc/doxygen/bugs.html
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
DEPRECATED! use ‘adapter srst delay’ not ‘adapter_nsrst_delay’
DEPRECATED! use ‘adapter srst pulse_width’ not ‘adapter_nsrst_assert_width’
Info : clock speed 400 kHz
Info : STLINK V2J39S7 (API v2) VID:PID 0483:3748
Info : Target voltage: 3.111903
Info : at91samd21g18.cpu: Cortex-M0+ r0p1 processor detected
Info : at91samd21g18.cpu: target has 4 breakpoints, 2 watchpoints
Info : starting gdb server for at91samd21g18.cpu on 3333
Info : Listening on port 3333 for gdb connections
target halted due to debug-request, current mode: Thread
xPSR: 0x61000000 pc: 0x00000288 msp: 0x20002dd8
target halted due to debug-request, current mode: Thread
xPSR: 0x81000000 pc: 0x00000288 msp: 0x20002dd8
** Programming Started **
Info : SAMD MCU: SAMD21G18A (256KB Flash, 32KB RAM)
** Programming Finished **
** Verify Started **
** Verified OK **
shutdown command invoked
I think success here. But no joy via device manager
Rewriting the bootloader should bring XIAO back to life. Also, since the boot loader area is protected, I think that the same trouble will not occur again.
Creator:
Why doesn’t Seed Studio just release a part that works properly. Surely, they know how to fix this, dont they read these posts. Here we are floundering about in the dark when this is their responsibility…right?
I’d add a couple of other suggestion. Those pads for reloading : no way holding pins against them is a functional solution. I tried many many times with zero luck. Soldering pins to them worked first time, HOWEVER, after the many tries needed to get the part back alive the pads broke off the PCB. I see on the schematic where the connect to the chip BUT see no way to actually make that connection. Some improvement needed there considering the need for reloading the bootloader.
Another suggestion : ST-Link utility, won’t run on my updated Win10 machine, Several reloads tried. A deep search revealed that Java need be installed, after installing that still no run. Something else is required but who knows what that is.
I did receive great support from msfujino on the forum and ultimately got one of my two Xiao to be recognized.
$18 for the ST-Link plus many hours spent to resurrect a $4 part is not my idea of a desirable platform. Now that the same part is > $8 even lesser so.
Xiao is a wonderful idea that I’d love to add to my tool box but some changes are gonna be needed.
Last night a double reset would not get it going. This AM after a reload it suddenly appeared in device manager.
OK got the second Xiao up too, BUT to be recognized by device manager, it requires a double reset on every power cycle.
After loading an old tried & true program the second Xiao is now behaving & no longer need the double reset. Odd, I know. Callin us as I see um here.
I haven’t bricked my XIAO yet. If I do I would have desolder it. But normal programming is a complete pain. Even a successful one ends with the Arduino IDE thinking there was an error:
Sometimes it works. Sometimes I need a double reset, then it appears as another COM port, so I have to change the IDE to match and then change it back as when my program runs it goes back to the original COM port.
Sometimes device manager will see the port but the IDE won’t, even if I quit and reload it. I haven’t found a consistent way to just load my program, like there is with every other board I have used with the Arduino IDE.
I get about 1 in 3 faulty uploads in a couple of different categories. Worse than any other chip. I also see the com port shuffle that you describe. I’m in contact with the makes of ‘ST-Link Utility’ to see why that important tool doesn’t load and run. Lotta things I like about the Xiao but I’m not yet sold on it being redi for prime time. Sure don’t like that the price has nearly doubled since the first batch I bought a few months ago.
I was able to recover my xiao by double tapping the reset pad shorted to ground to get it into USB bootloader mode, then deleting all the files in the drive, and replacing it with circuit python. I was then able to upload from arduino again, replacing circuit python.
