SerialUSB class

[asipo]

Hi Avik. I want to use the USB port as a serial one without the need of USB to serial conversion chip like CP2012, just like maple and stm32duino bootloader. I think the SerialUSB class does that job. But you mentioned that it is not supported yet. I wonder if you have a plan to complete the implementation of that library. Thank you.

[avikde]

I've gotten it working with the F303v variant (on a F303 discovery board) and the F373 variant (on a custom board) with the SerialUSB library that's included. I haven't used it extensively but you can try it out.

On Sat, Oct 29, 2016 at 9:16 AM, asipo [email protected] wrote:

Hi Avik. I want to use the USB port as a serial one without the need of USB to serial conversion chip like CP2012, just like maple and stm32duino bootloader. I think the SerialUSB class does that job. But you mentioned that it is not supported yet. I wonder if you have a plan to complete the implementation of that library. Thank you.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/avikde/koduino/issues/17, or mute the thread https://github.com/notifications/unsubscribe-auth/ADCURxuqf-0kU8byrLhcaqQEDM1gbD0Zks5q40dBgaJpZM4KkHD- .

[asipo]

Thank you for your prompt reply. I think a bootloader is necessary for DFU upload(and corresponding option in Arduino IDE), which I cannot find. Can you please give me a more detailed instructions?

[avikde]

I'm confused. Every STM32 chip I know of comes with a DFU bootloader. On your board you have to connect the USB pins, and have some way of resetting to bootloader (e.g. set BOOT0=high, then toggle NRST low then high). You should be able to enumerate the board with dfu-util's list command (and this is completely unrelated to any code libraries). If that works, dfu-util will also be able to upload code.

On Sat, Oct 29, 2016 at 11:45 AM, asipo [email protected] wrote:

Thank you for your prompt reply. I think a bootloader is necessary for DFU upload(and corresponding option in Arduino IDE), which I cannot find. Can you please give me a more detailed instructions?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/avikde/koduino/issues/17#issuecomment-257098797, or mute the thread https://github.com/notifications/unsubscribe-auth/ADCUR8EwGHUDEKB0318dqpsXUSgAAWMJks5q42ongaJpZM4KkHD- .

[asipo]

Yes. My STM32F373CCT6 device appears as a "STM Device in DFU Mode" in device manager when BOOT0 = high. And also it appears as a COM port with STM's virtual com port driver when BOOT0 = LOW.

I think my question is not correct, sorry for the confusion. What I am talking about is the method as in https://github.com/rogerclarkmelbourne/STM32duino-bootloader. It works fine with F103 board I have. When you say "enumerate the board", I think you mean the way to reconfigure D+ line as explained in the above link. So what I mean is the bootloader that updates firmware, reset the device and then make itself become a serial device, by itself, not by other hardware.

[rogerclarkmelbourne]

The F1 series does not have built in USB DFU support (I suspect the F0 series may not have it either) It has a Serial bootloader, which can be accessed by pulling boot 0 high.

Hence the need for the STM32duino-bootloader on the F1 series so that we can upload over USB without external hardware.

BTW. I think there is a way to enter the F1's internal (Serial) bootloader from the application code, but I can't recall how its done, but I think there is an Application Note that describes how to do it, and the same thing may be available on the F3 etc

[avikde]

I see. I have basically no experience with the F1 series, but you are correct: while the F105 seems to have a DFU bootloader, the F103 doesn't http://www.st.com/content/ccc/resource/technical/document/ application_note/b9/9b/16/3a/12/1e/40/0c/CD00167594.pdf/ files/CD00167594.pdf/jcr:content/translations/en.CD00167594.pdf

I don't have any knowledge to contribute about a custom bootloader... however, I can say that I've had good luck using an FTDI chip (which costs $2 https://octopart.com/search?q=ft231x) to auto reset into bootloader and out without any buttons or additional circuit elements, and as a bonus you get transfer rates of several Mbps when the chip is running which I doubt are possible with the virtual com port.

On Sat, Oct 29, 2016 at 6:10 PM, Roger Clark [email protected] wrote:

The F1 series does not have built in USB DFU support (I suspect the F0 series may not have it either) It has a Serial bootloader, which can be accessed by pulling boot 0 high.

Hence the need for the STM32duino-bootloader on the F1 series so that we can upload over USB without external hardware.

BTW. I think there is a way to enter the F1's internal (Serial) bootloader from the application code, but I can't recall how its done, but I think there is an Application Note that describes how to do it, and the same thing may be available on the F3 etc

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/avikde/koduino/issues/17#issuecomment-257118997, or mute the thread https://github.com/notifications/unsubscribe-auth/ADCUR_rHsoEQpe2d7bL-_bzh6KaQQ3Eyks5q48RYgaJpZM4KkHD- .

[rogerclarkmelbourne]

Thanks Avik, I was not aware of the DFU functionality on the F105.

The bootloader was developed by Leaflabs so that they could product a product that needed the minimum of components / cost.

There are other ways of uploading, e.g. Serial and SWD etc.

In terms of DFU speed, the bootloader seems to be about as fast as the other options, because the majority of the time to flash the device seems to be waiting for the each flash page to be individually erased.

I'm sure the built in DFU would be a bit faster as the stm32duino bootloader is compiled for size not speed and is not hand optimized / assembler etc

[rogerclarkmelbourne]

BTW. In terms of what the OP wanted.

I presume what they want is probably just USB CDCACM + method to enter the built in DFU bootloader (on the F3) e.g. using a magic reset sequence via the USB Serial.

[asipo]

It would be ideal that the USB port is seen as a COM port, or just recognized as a usual Arduino board. So from then, firmware upload and UART communication are possible in Arduino IDE without USB to UART conversion chip, just like the way done in F103 with STM32duino bootloader and upload method change in Arduino.

[asipo]

Hi Avik. The serialUSB library works on F373 board(BOOT0 = L). Also with usb driver(zadig 2.2) and ST's virtual com driver, I was able to upload .bin using dfu-util(BOOT0 = H). But the problem is that I have to reset the board to make it work. After turning off and on the power of the board or unplugging and plugging USB cable, the computer does not recognize the serial port. I have to push the reset button to make the com port appear in device manager.

Is there anything I missed? Can you tell me how you did it?

[avikde]

Hi asipo, Unfortunately that seems about right to me. I had the same experience when I implemented with the F303 discovery board. It's possible to reset the USB using a digital pin so that the usb connection re-enumerates. However, I would have to do a lot more digging to get more info on that and I won't in case you are not making your own boards.

Sorry I don't have much experience beyond tests on two board. I have only used SerialUSB sparingly since I moved to UART+FTDI for higher bandwidth, auto reset, etc. (not to mention the F301 doesn't have USB).

On Wed, Nov 9, 2016 at 5:43 AM, asipo [email protected] wrote:

Hi Avik. The serialUSB library works on F373 board(BOOT0 = L). Also with usb driver(zadig 2.2) and ST's virtual com driver, I was able to upload .bin using dfu-util(BOOT0 = H). But the problem is that I have to reset the board to make it work. After turning off and on the power of the board or unplugging and plugging USB cable, the computer does not recognize the serial port. I have to push the reset button to make the com port appear in device manager.

Is there anything I missed? Can you tell me how you did it?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/avikde/koduino/issues/17#issuecomment-259384796, or mute the thread https://github.com/notifications/unsubscribe-auth/ADCURxgPcX5fuSkJh75qBaqDRJ21iIfnks5q8aPVgaJpZM4KkHD- .

[asipo]

My board has a GPIO connected to the USB D+ line via p-channel MOSFET, so D+ can be set HIGH when necessary. I did some experiment to check what happens in D+ line when the board is reset. I found that the USB is recognized as a COM port when D+ is maintained HIGH for ~1s after power up. I don't know this is reliable and conforming to USB standard.(USB stuff is too complicated..) Anyway this is implemented in setup(), so when the board is powered first and then the USB cable is plugged, the problem remains. Do you have any idea on this? (like detecting USB connection..)

[avikde]

I agree that USB is too complicated.

On my custom board it is pin -> PMOS -> series 1.5k resistor -> D+. I have the function "setUSBDisconnectPin(uint8_t pin)" defined, so in your sketch before Serial.begin you should call that function. That worked for me (but again, I have only debugged minimally)...

On Thu, Nov 10, 2016 at 3:02 AM, asipo [email protected] wrote:

My board has a GPIO connected to the USB D+ line via p-channel MOSFET, so D+ can be set HIGH when necessary. I did some experiment to check what happens in D+ line when the board is reset. I found that the USB is recognized as a COM port when D+ is maintained HIGH for ~1s after power up. I don't know this is reliable and conforming to USB standard.(USB stuff is too complicated..) Anyway this is implemented in setup(), so when the board is powered first and then the USB cable is plugged, the problem remains. Do you have any idea on this? (like detecting USB connection..)

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/avikde/koduino/issues/17#issuecomment-259625228, or mute the thread https://github.com/notifications/unsubscribe-auth/ADCUR3s8xgrz8NpRw8V60Wh7n8cYGL1lks5q8s-PgaJpZM4KkHD- .

[asipo]

It works on my board too. But still, reset is required to get it recognized as a COM port when USB cable is plugged after power up. Do you have any function that checks the status of USB connection?

[erwincoumans]

I tried using the SerialUSBClass on STM32F303 Discovery but don't see anything using the Arduino IDE Serial Monitor. I'm uploading the sketch below using dfu-util, adding a jumper on the BOOT0 pins. The upload succeeds fine. Then removing the BOOT0 jumper, and switching the USB connector, the USB port is visible but no output.

Does anyone have a simple example, with explanation how to connect the cables on STM32F303 Discovery board?

Thanks!

#include <SerialUSBClass.h>

void setup() {
  // put your setup code here, to run once:
  Serial.begin(115200);
  Serial.println("setup\n");

}

void loop() {
  // put your main code here, to run repeatedly:
  Serial.println("loop\n");
  delay(1000);
}

[avikde]

@erwincoumans that exact sketch worked for me:

• upload using ST-LINK (connect to center mini USB) or DFU (right corner mini USB, need to put into bootloader mode first)
• After the upload, unplug, and plug into the right miin USB (which says USB USER next to it). On Windows, it takes a moment to set up the VCP, and then a new COM port appears, on Mac it should be called something like /dev/tty.usbmodem* IIRC. If you open that COM port you should see your "loop" messages.
• If I remember correctly, you may need to unplug and replug after resetting the microcontroller unless there is a USB disconnect pin, which you can set using setUSBDisconnectPin

[erwincoumans]

Thanks for confirming. Uploading works using dfu-util.

The /dev/tty.usbmodem* only appears when connecting to the center mini-usb (which shows no serial messages), not when plugging in the right mini-usb, even after unplugging and removing the boot0 jumper. If I ever figure out the issue, I'll reply here.