Was working, now stopped

I have a Blue Pill board. I managed to program the STMDuino boot-loader to the board using STLink (generic_boot20_pc13.bin). I then was able to upload a Blinky program to it using the Arduino IDE and selecting Maple Mini as the target board. I played around with this to convince myself the compile/load was actually working, which it was. Then I loaded another sketch but it failed to compile because of a library incompatibility. Then I went back to the Blinky sketch and found I can compile it but I can no longer upload it. Here is the error:

maple_loader v0.1
Resetting to bootloader via DTR pulse
Reset via USB Serial Failed! Did you select the right serial port?
Searching for DFU device [1EAF:0003]…
Assuming the board is in perpetual bootloader mode and continuing to attempt dfu programming…

dfu-util – (C) 2007-2008 by OpenMoko Inc.
This program is Free Software and has ABSOLUTELY NO WARRANTY
Couldn’t find the DFU device: [1EAF:0003]

BTW, there is no COM port selection available.

Joe

So, I managed to get it working again by pressing the board’s reset button just before the compiler entered the upload mode. Now I have a COM port showing in the IDE and everything seems to work repeatedly. Is there something I should be doing to avoid getting back in this mode? BTW, I didn’t have to do the resistor mod to make it work; could this be part of the problem?

Mines super flaky as well. Sometimes forced to reflash the bootloader as well and I’ve done the resistor mod.

I’m on OSX.

Is there something I should be doing to avoid getting back in this mode? BTW, I didn’t have to do the resistor mod to make it work; could this be part of the problem?
Usually it works with 10k resistor fine.
It may happen it stops working from time to time. Do not panic -> that is my recommendation

[cyberheater – Thu Apr 05, 2018 3:22 pm] –
Mines super flaky as well. Sometimes forced to reflash the bootloader as well and I’ve done the resistor mod.

I’m on OSX.

OSX is super flaky with serial bootloader (even with every *serial USB stuff not only STM32). Since the beginning of STM32duino I was fighting with OSX. From version to version it was better, sometimes total hardware crashes. Hardware reset after uploading was never really functional.
The reason is a internal security thing within OSX and you can only disable every security stuff on OSX permanently – bad idea.
But there are so many other upload options:
ST-Link (even with a nucleo board or those cheap V2 clones) (I prefer the ST-Link V2)
Black Magic Probe
and so on.

If you really need the serial bootloader and OSX, be sure to know “perpetual bootloader mode”
—> http://wiki.stm32duino.com/index.php?ti … bootloader

[joedarock – Thu Apr 05, 2018 3:04 pm] –
[…] and selecting Maple Mini as the target board. […]

Did you also check which bootloader version was selected in the bootloader menu?

madias:
Where did you get the idea I’m using OSX? It’s Win10.

edogado:
I tried both available bootloaders and both behave pretty much the same.

Building your sketch with the correct bootloader version is important because this defines the sketch code base: if you build with the wrong bootloader option then your sketch addresses will be wrong and your sketch won’t work.
This could explain why you cpuldn’t find the Serial device after upload..
Another possible cause of troubles in automatic reboot is using the nano.specs linker option: there is an old thread about this.

Hope this helps..

Best, E.

Well, it works 9 times out of 10. It seems to only have trouble when I first start the Arduino IDE. When that happens, I get no com ports in the “port’ selection field. If I hold the reset button at the end of the compile process just before entering the bootloader, it works and continues to work until I restart the IDE.

FWIW

Joe

[joedarock – Fri Apr 06, 2018 7:21 pm] –
madias:
Where did you get the idea I’m using OSX? It’s Win10.

edogado:
I tried both available bootloaders and both behave pretty much the same.

OSX was belong to cyberheater.
You should consider using a different USB-Cable. Mostly such symptoms were caused by (nearly) faulty USB-cables.

I then was able to upload a Blinky program to it using the Arduino IDE and selecting Maple Mini as the target board.
That’s wrong for the bluepill. You must select:
generic STM32F103C Series
If you upload it with “maple mini” settings it could be that the bootloader got corrupted, so upload the bootloader for the bluepill again and select the correct board.

I already tried that early in the debug process.

I’m unsure if it is related, but I also struggled with intermittent failures, forcing me to flash the bootloader again using serial. I found out the bootloader stopped working after I loaded a sketch on it containing this particular code:
void setup() {
Serial.begin(115200);
while (!Serial) {
; // wait for serial port to connect. Needed for native USB port only
}


What exactly should this code do? What do you expect? What is in the loop? This should not compile at all.

[stevestrong – Fri Jun 01, 2018 9:48 pm] –
What exactly should this code do? What do you expect? What is in the loop? This should not compile at all.

The code example provided is only part of a complete sketch. Like for example the Arduino example sketch StringAppendOperator.

Why would it not compile? It’s just an empty loop waiting for the Serial object to return true (boolean operator defined in class Serial).

[freynder – Fri Jun 01, 2018 10:28 pm] –
Why would it not compile? It’s just an empty loop waiting for the Serial object to return true (boolean operator defined in class Serial).

I guess you already knew that judging from your other posts in this forum where you advise to wait for serial. So you probably meant the missing } . I only provided an partial exerpt of the code, sorry for not being clearer.

I just tested this code and I could upload it with Arduino IDE 20 times consecutively using stm32duino bootloader.
void setup() {
// put your setup code here, to run once:
Serial.begin(115200);
while (!Serial); // wait for serial port to connect.
}

void loop() {
// put your main code here, to run repeatedly:

}

[stevestrong – Sat Jun 02, 2018 7:20 am] –
I just tested this code and I could upload it with Arduino IDE 20 times consecutively using stm32duino bootloader.
…
Win10 64bit.

Thank you for testing. I would be interesting if someone could test it in linux as well.
Also: the USB hid bootloader does not seem to have the same problem.

I tested the code on Win10, 64-bit and Ubuntu 17.1, 64-bit for 10 times. I could upload every time.

Check the file hardware/Arduino_STM32/tools/linux/maple_upload

Which core you used ?
As you raised an issue on Arduino_Tools, it is for STM core?
STM core does not support DFU upload nor vect tab offset yet….

I’m using Roger’s Arduino STM32 core. It worked intermittently. Yesterday I was convinced the trigger was waiting for the !Serial but not anymore today.

I’m usually using PlatformIO for my development. I tested the issue using Arduino IDE yesterday to make sure it was not PlatformIO related before posting about the issue. I could easily reproduce the issue then, but PlatformIO was still running in the background. I suspect this may have something to do with it.

I tested again this morning without PlatformIO running and could not reproduce the issue anymore. So I closed the github issue for now and will investigate further what are the exact conditions for my issue and report it here.

Thanks for your help.