USBSerial and Serial Terminal

I’ve been thinking about this also but unfortunately I don’t know enough to make it work. Here’s some info about how STM32duino bootloader does reset.

https://github.com/rogerclarkmelbourne/ … bootloader

On “generic” boards, the USB reset (to force re-enumeration by the host), is triggered by reconfiguring USB line D+ (PA12) into GPIO mode, and driving PA12 low for a short period, before setting the pin back to its USB operational mode.

Since there’s no USB-Serial converter in STM32 like in Arduino (CH340, FTDI, etc) there is no DTR pin also to trigger reset.

There must be some way how Arduino IDE detects that COM port is ‘ready’ to be opened with Arduino boards if it can capture all Serial data from the beginning of the sketch. I guess something similar is needed to STM32duino bootloader also.

The workaround I use is:
void setup() {
Serial.begin();
while ( !Serial.isConnected() ) ; // wait till serial connection is setup, or serial monitor started
...
}

@Michael,

The USB CDC device is implemented in the User Application and not the bootloader code. So if the IDE tries to “re-open” the Serial Terminal too soon, it will fail. I guess that careful timing between DFU completion and Application running might catch an enumerated CDC. But it would be risky.

@Steve,

Yes, I know that I can hang until isConnected() is true. This will not compile on a regular Arduino.
And many applications only use Serial as an “extra” e.g. to show some diagnostic information.

Yes, I can delay for a “long time”. This will work on any Arduino. The punter just has to click on the Terminal icon “fast enough”

I could use a timeout with isConnected() or Serial != NULL on a Leonardo. It adds messy conditionals to a simple Arduino sketch.

The ideal arrangement would be if “click on the Terminal icon” would restart the BluePill. i.e. the Terminal opens successfully. The BluePill starts USBSerial. Every byte is caught. Similar behaviour to any other Arduino.

David.

david.prentice wrote:
The stm32duino bootloader will clear an open Terminal and upload just fine. At the end of the DFU upload, it attempts to re-open the Serial. This fails because the USBSerial does not start until the program has started.

The stm32duino bootloader uploads fine if there is no open Terminal. The program runs. You can click the Terminal icon. You lose the first bytes of Serial. The Terminal icon does not reset the program.

I tried changing boards.txt and restarted the IDE. It made no difference.
I can still upload a sketch. But if I have a teminal open when I start the build, I get:
...
Sketch uses 46,472 bytes (70%) of program storage space. Maximum is 65,536 bytes.
Global variables use 4,048 bytes of dynamic memory.
maple_loader v0.1
Resetting to bootloader via DTR pulse
Searching for DFU device [1EAF:0003]...
Found it!

Opening USB Device 0x1eaf:0x0003...
Found Runtime: [0x1eaf:0x0003] devnum=1, cfg=0, intf=0, alt=2, name="STM32duino bootloader v1.0 Upload to Flash 0x8002000"
Setting Configuration 1...
Claiming USB DFU Interface...
Setting Alternate Setting ...
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
Transfer Size = 0x0400
bytes_per_hash=929
Starting download: [##################################################] finished!
state(8) = dfuMANIFEST-WAIT-RESET, status(0) = No error condition is present
Done!
Resetting USB to switch back to runtime mode
processing.app.SerialException: Error opening serial port 'COM28'.
at processing.app.Serial.<init>(Serial.java:127)
at processing.app.Serial.<init>(Serial.java:66)
at processing.app.SerialMonitor$3.<init>(SerialMonitor.java:93)
at processing.app.SerialMonitor.open(SerialMonitor.java:93)
at processing.app.AbstractMonitor.resume(AbstractMonitor.java:110)
at processing.app.Editor.resumeOrCloseSerialMonitor(Editor.java:2246)
at processing.app.Editor.access$2400(Editor.java:77)
at processing.app.Editor$DefaultExportHandler.run(Editor.java:2212)
at java.lang.Thread.run(Thread.java:745)
Caused by: jssc.SerialPortException: Port name - COM28; Method name - openPort(); Exception type - Port not found.
at jssc.SerialPort.openPort(SerialPort.java:167)
at processing.app.Serial.<init>(Serial.java:116)
... 8 more
Error opening serial port 'COM28'.

Very strange … it seems that you have drivers issue
Look at your PC control panel. Is there an additional COM port (USB Serial port) when you connect the bluePill or maple to the USB port ?

I edited the C:\Users\David\AppData\Local\Arduino15\packages\stm32duino\hardware\STM32F1\2017.3.26\boards.txt

When I look at Device Manager, I see “Teensy USB Serial (COM28)” on my Win7-32 Laptop
When I look at Tools->Port in the IDE, I see “COM28 (Maple Mini)”

I have a Mouse in one USB port, the BluePill in the other USB port.

I can watch the successful upload in Device Manager.
The COM28 disappears. Atmel USB Devices->Maple DFU appears. The COM28 appears when complete.

I presume that the IDE script is trying to open the COM port as soon as the DFU has completed but before the CDC has been started by the User Application.

Since the MapleMini bootloader gets started correctly, this means that a Reset is getting to the BluePill.
I would be quite happy with closing the Serial Terminal before Uploading.
If “opening” did a successful Reset that would be fine. (like the early Arduino IDE used to behave)

David.

The same behavior for me: no reset when I open the serial monitor window. It was always this way.

So Is the While(Serial.isConnected()) same as while(!Serial) in Arduino sample sketches.

is this the same behaviour on all platforms, win/mac/linux?
on linux, i usually plug my devices into the hub in a certain order; stlink, target usb, target uart1, maybe target uart2 … …
then /dev/ttyUSBn usually toggles between 0 and 2 on uploads and i change the port ( repeatedly )

srp