USB features

[fpistm]

Need to support USB features:

• DFU --> Add dfu-util upload method #351 for built-in ST bootloader. Other bootloader will be handle by another PR, ex Enabling Bootloaders #411.
• VCP -->1.5.0

First PR to rework USB part #91

DFU is mainly requested for generic STM32 based boards without STLink (ex: BP and MM)
Note: USBSerial has been integrated in this PR #61
See #388

[hei5enbrg]

native STM boot-loader supports dfu right?
BTW for devices which doesn't have boot0 button (which is required to get into boot-loader in the system memory) you still might be able to jump to system boot-loader from application. maybe you can wait for a specific command or a button press and jump to system memory.

another approach here they use first 0x2000 bytes for the custom usb-dfu compatible boot-loader.

[kaofishy]

Problem is some STM32 with USB has no USB bootloader, only UART/I2C/SPI (eg the venerable F103, or even the newer L052/62). So the ability to add DFU from within a sketch would be nice to have, though USBSerial is probably higher priority.

[fpistm]

I think, VCP will come first.

[sstaub]

I'm missing an USBDevice library like on mbed

[hasenbanck]

Is there any timeline for VCP support? I'm currently adding support for a F765 board and would like to include VCP to support Marlin without using a USB to TTL chip. For the time beeing using an external USB to TTL works fine, but before opening the hardware design it would be best to have VCP support.

Is there any way I could help out to accelerate the development of the VCP support?

[fpistm]

Hi @hasenbanck, currently not, time is always the missing ingredients.
I try to do a plan for all stuff to do on this core but currently I'm busy on other task.
Any contributions are welcome and greatly appreciated.

[hasenbanck]

I guess that #91 contains the VCP stuff (including other features). Should I consider working on that pull request? What is missing in that PU in your eyes? I read the discussion of the request, but I only found a "In fact, it was functionnal, but required some clean. First will be to rebsse it properly"

[fpistm]

I've made lot of clean in the core, I guess this will require more than a rebase and performance was not at the expected level.

[hasenbanck]

Okay, I won't look into the issue deeper for now. First I will try to upstream our board definition into your repository and then I need to write a Marlin integration for the board first. Once that is up and running, I will look into the VCP stuff and of course will aid in any testing I can do.

[hasenbanck]

@fpistm do you plan on working on the VCP anytime soon? If not, I will start working on it once I finished my sideproject. I think I would then take #91 and rip out the VCP parts, clean it up and rebase the changes to the current master.

[fpistm]

Hi @hasenbanck
it is always planned. :(
From the current view, I will release an HardwareTimer library (in october) then work on this subject after.
What I've planned for USB part is at a first step move the USB part in library (HID), then add the VCP after a deeply review of the first implementation done. Speed was not not at the expected level (very slow).
Moreover, the configuration in the variant could be more generic and removed from the variant (or partially).

Anyway any contribution are welcome and greatly appreciate.

[hasenbanck]

Okay, I understand. Once I finished my side project (https://github.com/hasenbanck/exa_tim) I will look into the #91 branch and I will try to get it to work on my board variant.

Maybe it's best to evaluate why the speed was not at the expected level and what changes are needed to rebase the current work. Maybe you can then alter built up on my experiences I gained.

[alexwhittemore]

@fpistm at the risk of this being an incorrect and annoying place to ask the question, I'm REALLY confused about the state of USB serial support, and it looks like the stm32duino.com forum is going into sunset so I'm not sure where best to ask about it.

Background: I've got a blue pill, and I'm trying to get a-sketch-any-sketch running on it, and stopped at a breakpoint. I landed here, because it appears to be the most up to date and board-complete STM32 Arduino core project.

In the board selection, I've got "Board Part Number: Blue Pill F103C8". It seems to me that, by selecting "U(S)ART: Enabled (Generic Serial)" and "USB Support (if available): CDC (Generic Serial supersede U(S)ART", I should get a USB serial device. But this doesn't seem to happen. The sketch compiles and loads (if I disable eitherr, the Serial library isn't linked and compilation fails), but no USB device enumerates.

Am I missing something in this process?

EDIT: No sooner did I post this than it suddenly started working for me: apparently I need to physically unplug and replug the USB side - simply resetting the uC doesn't seem to be enough. Should this be the case? Oh and of course - I'm on macOS Mojave.

[fpistm]

@alexwhittemore
Seems strange as we manage to reenumerate automatically.
Or maybe you face an issue with the flash which does not reset the board automatically.
I will retest on MAC.

[alexwhittemore]

@fpistm Well, at least it's SUPPOSED to work :). I'll keep an eye on it and see if I can get a repeatable A/B behavior or something.

I'm running into a separate issue where I can't seem to set breakpoints using VSCode, so I'm setting up a virtual Ubuntu environment anyway. I'll see how it plays there.

[Sambo007]

Try this in 'platformio.ini', please:
;platform = ststm32 ; comment this out
platform = [email protected]

Basically if you check the log you will notice after version 4.5.0, PlatformIO authors switched from Roger Clark's libs/platform, which automatically links the usb-serial driver to official STM32 Core for Arduino, which does not and couldn't figure out a way to do it.

Cheers...

[alexwhittemore]

Interesting info! Although as of this post, I'm not actually using platformio. I am, in parallel, trying to set up a working platformio toolchain as a reference, and also a working open source toolchain.

[fpistm]

@alexwhittemore you use Arduino IDE ? or other environment ?
I have tested and this work without any issue.

[alexwhittemore]

@fpistm I'm not sure why environment should matter, other than of course the OS that's trying to host the VCP. Anyway, I did just retrace all my steps in the Arduino IDE, with the following sketch:

void setup() {
  // initialize digital pin LED_BUILTIN as an output.
  pinMode(LED_BUILTIN, OUTPUT);
  Serial.begin(9600);
}

int i = 0;

// the loop function runs over and over again forever
void loop() {
  digitalWrite(LED_BUILTIN, HIGH);   // turn the LED on (HIGH is the voltage level)
  delay(1000);                       // wait for a second
  digitalWrite(LED_BUILTIN, LOW);    // turn the LED off by making the voltage LOW
  delay(500);                       // wait for a second
  Serial.println(i++);
}

When I load the sketch, it starts blinking just fine. But no virtual com port appears, at any point, whether I reset or replug. FWIW, a difference between this time and last time I posted is that I WAS using an ST-Link that supplied power, and now am not. That is, a replug means a power cycle, where before it didn't.

Curiously, with the sketch above, the STM32 crashes after 53 seconds, and my blinky stops blinking. Always in the "on" part of the sketch, but if all the timing is deterministic, that could be chance.

Also curious, if I simply comment out the serial statements, it never does crash - just keeps on blinking forever (that I've sat here).

It sure does smell like there's a bug in the USB code somewhere around handling a USB plug event that never happens, or happens too early, or happens to late, or whatever, and the stack times out waiting on it. But I don't know enough about the USB protocol to offer any specific insight.

[alexwhittemore]

A little more testing:

1. It's not 53 seconds deterministic. It's "some time around a minute, give or take." Which makes it all the more odd that it always stops with my LED "on"
2. I added external power to the board so I could replug it without power cycling. The VCP only appears if I replug (when it appears, it works fine in serial monitor). If I DO replug, the sketch runs fine forever. If I DON'T replug, the sketch crashes after a minute or whatever.

This certainly sounds like a bug in the USB stack on the STM32.

[BennehBoy]

It's halting because the serial buffer is full.

What board are you using and what menu options have you chosen?

[alexwhittemore]

It's halting because the serial buffer is full.

That's a SUPER odd reason to halt. I don't think I've ever encountered an embedded system that completely ceased function just because the buffer was full, and certainly not vanilla AVR arduino. Is that common? Or just a misconfiguration on my part?

What board are you using and what menu options have you chosen?

Blue Pill STM32F103C8, "Generic 'Serial'", CDC (Generic 'Serial' superscede USART), Low/Full Speed, Debug (-g), Newlib Nano (Default)

[BennehBoy]

It's due to DTR, if the serial emptied due to the data being read then it will continue, so it's actually just spinning.

I'm unsure which OS you are using, but there's a known issue with USB hardware on the bluepill, they usually come with an incorrect D+ resistance so you must either replace or augment, see the wiki here -> http://wiki.stm32duino.com/index.php?title=Blue_Pill

[fpistm]

Did you manage to have USB working with BP? Example using Roger's core?
As already pointed, I guess this could also be linked to DTR or maybe an issue with resistor value which is wrong on BP.

[alexwhittemore]

Not exactly, but I haven't tried much beyond the last post there. Pursuing STM32s was sort of a side project in getting a toolchain up and running, mostly because I have many lying around. But the main project right now is actually on a SAMD21, so that's where I've been focused. I'll try changing the resistor - I'd read about that elsewhere and it'd make sense for enumeration. But I'm very skeptical that it has anything to do with the serial buffer filling up and halting code execution. Overflow when unplugged vs normal function when terminal connected seems to have little to do with the physical layer.

[BennehBoy]

Believe it or not, I can physically demonstrate with ease... if the hardware is connected but nothing is actually reading the serial data then the device will pause until the buffer is cleared. This was also a problem on Roger's core but they recently backed out a change that introduced it. @fpistm it may be worth us looking at that.... Here's the thread on it -> https://www.stm32duino.com/viewtopic.php?f=3&t=4439&hilit=dtr

This coupled with your USB being partially connected (BP think's it's OK but computer does not) would give the above.

You can test this by powering the board from a DC supply, you won't see the same behavior (unless the issues is worse on this core!)

[fpistm]

@BennehBoy,
This is closed to #444. I've only an issue on enumeration after a unplug/plug on Windows if Port has already been opened.

[BennehBoy]

@fpistm thanks for the reminder, I clearly was not imagining the issue them 😉

[alexwhittemore]

@BennehBoy

This coupled with your USB being partially connected (BP think's it's OK but computer does not) would give the above.

This is pretty definitively what's going on. I replaced R10 with a 1.5k (actually, a stack of 3 5K, 1.666 is close enough) and now my bluepill reliably enumerates.

I then tested with a terminal connected/disconnected. My sketch just prints an incrementing int each loop, so I guess that's 2 bytes (2 chars) for each loop, for two digit numbers? It lasts 27 2-digit numbers before halting. What's odd is that, when I do reconnect, it just picks up where last it halted. So it's not like it's spitting out the entire buffer. I'm not really sure how UART with flow control is supposed to work, but shouldn't I get a quick integer vomit then it carries on printing every (1s or so)?

Anyway TL;DR, it enumerates properly with a corrected USB resistor and the sketch halts if the buffer isn't read out.

HOWEVER, If I disconnect USB totally and power from an external source, the sketch still does stop on a full buffer. So it seems irrelevant if USB is enumerated. It only matters whether the USB Serial support is compiled in.

[fpistm]

You wil need #444.
You can also add while(!SerialUSB); after the Begin.

[BennehBoy]

Irrespective of #444 the behavior is different to what was happening on Roger's core then, that would work just fine whilst the hardware was disconnected. Fingers crossed it's now resolved.

[alexwhittemore]

@fpistm To be clear, does that mean this feature update integrates #444 And therefore fixes the problem? I’ll pull an update now and do a before/after comparison to see if the behavior is as expected. Thanks so much for the hard work!

[fpistm]

#444 is merged since several weeks.

This issue was open to track 2 points linked to USB:

• VCP which is available since 1.5.0
• DFU upload method which is now available in the master (for STbuilt-in bootloader).
  That's why I close it.
  Some other USB stuff are already track in other issue/PR. If you met a new one not tracked properly, do not hesitate to open a new issue.
  Last time I've tested USB with MAC with a BP I did not had your issue. But maybe it's always present.

[alexwhittemore]

Ahh thank you - sorry for hijacking the issue then forgetting I'd hijacked it :)

I'll double-check functionality across all of the relevant points to acquaint myself, and open other issues appropriately if I find something odd.

Thanks so much, again!