Bootloader Stuck 1EAF:004?
Posted: Tue May 25, 2021 12:50 am
Got my STLINK working, and flashed "generic_boot20_pc13" to my fresh new Blue Pill clone (F103C8). Rapid flash on boot and shows up as [1EAF:0003] in lsusb, and after a few seconds the flashing stops and the usb identifier changes to [1EAF:0004]. So far so good. So far all in Linux.
Here is where I started having problems, and I tried in both Windows and Linux with different errors, but similar effect.
Windows:
Linux:
Although the Linux output is a little less hopeful, in both operating systems the Arduino IDE appears to successfully initiate a DTR pulse reset, and the device comes back up rapidly blinking like it always does for the first few seconds, but stays blinking (as I believe would be expected). What's weird is when I check lsusb on Linux, the device is showing up [1EAF:0004] even immediately after the DTR reset, and even though it visually appears to be in the bootloader.
It seems like after a DTR reset the bootloader is coming back with the USB device identifier [1EAF:0004] instead of the expected [1EAF:0003] associated with the bootloader, and this is causing it to now show up as an eligible target.
If anybody has any suggestions, or ideas what might be going on I'd appreciate it.
Thanks!
Here is where I started having problems, and I tried in both Windows and Linux with different errors, but similar effect.
Windows:
Code: Select all
mable_loader v0.1
Resetting to bootloader via DTR pulse
Searching for DFU device [1EAF:0003]...
dfu-util - (C) 2007-2008 by Open Moko Inc.
This program is Free Software and has ABSOLUTELY NO WARRANTY
Couldn't find the DFU device: [1EAF:0003]
timeout waiting for COM3 serial
Code: Select all
No DFU capable USB device found
dfu-util 0.7
Copyright 2005-2008 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2012 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to dfu-util@lists.gnumonks.org
Filter on vendor = 0x1eaf product = 0x0003
Waiting for /dev/ttyACM0 serial...Done
It seems like after a DTR reset the bootloader is coming back with the USB device identifier [1EAF:0004] instead of the expected [1EAF:0003] associated with the bootloader, and this is causing it to now show up as an eligible target.
If anybody has any suggestions, or ideas what might be going on I'd appreciate it.
Thanks!