USB-serial troubles

I use ST-Link to program my device and it works well, but oftentimes I’d like to be able to use serial for debug-output or input for data. Now, the problem is: after flashing the device with ST-Link the USB-serial doesn’t seem to get renumerated properly — it is there, it exists, but doesn’t actually work until I remove power to the device and plug it back in, the Linux-kernel complains about not being able to set DTS and DTR lines. Then there’s the issue of ~17 seconds wait-time after insertion of the device before the serial-port is actually useable.

At the moment I have resorted to using an external USB-serial adapter and set up my code to use Serial1 instead of Serial, but having an extra dongle is an ugly workaround. Is there some way of forcing renumeration at boot, and is there something that could be done about the ~17 seconds wait-time, or is it just something one has to live with?

In boards.txt there are 2 defines which enable the compilation of Serial USB.

But i cant quite recall if you need to add just the one about Serial USB or whether you need to also add the one about the bootloader to the STLInk upload menu option.

To be honest, these definitions have confusing names, and we should probably clean up the code and change the names..
But most people use Serial USB when they are using the bootloader

Check also your micro-usb cables…. I have 5 cables, with two of them it is impossible to enumerate USB serial….
But I am pretty sure that the latest code is enumerated correctly while usb is connected and the st-link is used for download. Compiler 4.9 is also working….
I am compiling source code by codeblocks, but I think this is irrelevant of enumeration anyway…..

Slammer wrote:Check also your micro-usb cables…. I have 5 cables, with two of them it is impossible to enumerate USB serial….

If you press the reset button on the blue pill (I’m assuming this is the modified blue pill you created yes?) does it enumerate again? If not, then you probably don’t have a functional setup.

Actually, I just grabbed the latest github (It has been a while ) and I’m seeing this same behaviour. I can flash it and it uploads fine but does not reenumerate. If I press the reset button it then does the right thing without having to unplug replug.

BTW: If you have the Arduino Serial Console open when you press reset, it is going to probably enumerate on a different ttyACM number

I fixed the problem using this change. I edited my stlink_upload script to look like this:
#!/bin/bash

openocd -f ~/openocd_cfg/ebay_stlink.cfg -c "program $4 verify reset exit 0x08000000"
exit

Replacing stlink_upload with this also works:
#!/bin/bash
openocd -f interface/stlink-v2.cfg -f board/stm32100b_eval.cfg -c 'reset_config none' -c "program $4 verify reset exit 0x08000000"
exit $?


Just for grins I pulled the development branch and it has the same problem of not enumerating.

Rick, is it better to use BMP instead of stlink?

Rick

I merged the development branch into the master a few months ago.

Actually,i think the development branch is behind the master, as there have been a few minor changes in the last few weeks and I have not merged the master back into the development branch.

However, because I forgot to merge back into the development branch recently, it does rule out the recent changes to making some vars in the USB code into volatile ( which was to fix issues with gcc 4.9 optimisation)

you could try checking out an older version ? ( though Im not sure how far you would need to go back), to see if this ever worked

I don’t think the problem lies with the USB firmware code. It seems like the stlink_upload script doesn’t effectively reset the chip after loading. I see there are shell commands that attempt to use methods to reset the board that don’t seem to work. I’m just offering up the openocd method of flashing and resetting as something that has worked without fail for me.

-rick

Rick Kimball wrote:I don’t think the problem lies with the USB firmware code. It seems like the stlink_upload script doesn’t effectively reset the chip after loading. I see there are shell commands that attempt to use methods to reset the board that don’t seem to work. I’m just offering up the openocd method of flashing and resetting as something that has worked without fail for me.

ah..

I noticed the latest version of the STM windows Stlink CLI, changed so that it requires a keystroke (enter) to exit, which was causing problems for the IDE.

But as I copied the CLI exe into the repo for the libmaple core, months ago, I didnt think it was an issue with that core. (As people would, on windows, be running the old version)

When i was messing around with the HALMAX core, I ended up removing the Run command as the reset command on its own seemed to be all that was needed, to get it to run the binary that had just been uploaded.

But the HALMX core doesn’t have Serial USB at the moment, so I wasn’t testing that aspect.

That long delay for the USB-serial port to become available in Linux is familar. See here.

Maybe it wasn’t clear from what I wrote. The changes I made by using openocd solved both the reset problem and eliminated the delay. When I upload now, it resets immediately after the code is flashed and then successfully enumerates in less than a second.

For those running modem manager there is a udev env variable that can be set to inform modem manager that the maple serial port isn’t a modem. It skips the AT cmd dance altogether. I took the simpler route and just uninstalled modem manager.

https://cgit.freedesktop.org/ModemManag … list.rules

Rick Kimball wrote:
<…> I took the simpler route and just uninstalled modem manager.

https://cgit.freedesktop.org/ModemManag … list.rules