USB Port on Discovery F4

Hello everybody,

is the usb port already supported by the library ?

Regards

Lucky1

Which usb port do you mean, the OTG or the USB client?

AFIK. In the F4 core the OTG port is configured, but I’ve not tested its operation.

You’d probably need to look at the AeroQuad forum about this, as the F4 core is based on the AeroQuad core (which originally came from the LibMaple core written by LeafLabs).

Note. The F1 core is also derived from LibMaple, but the AeroQuad copy was branched from LibMaple a few years ago, hence the code is somewhat divergent between the F4 and F1 cores.

I am working on this for the HALMX branch. There is a bunch of external HW needed to support USB like the connector. Have not had time to sit down with the docs a scope and the resistors that identify the type/speed of USB cable is attached. I have all the hardware to mount onto a breadboard, it is high on my to do list.

I think there was some recent work on the Areoquad F4 core, to fix some of the serial stream print stuff. I abandoned that core as there was too much customization needed for the different pin configuration which are anything but standard, between small pin and large pin chip packages, when mapped to Arduino type pins. I have sort of figured out ST’s mindset relating to some 2012 code which seems to apply to the Nucleo (RET*) chip packages.

Some of the issue is that the Arduino basline shares LED, D13, PWM, and SPI clock on the same pin. So there is no one to one mapping like there is with AVR libraries. Similarly USB shares one of the serial USARTS. This makes more work, as one has to design the application and peripherals, which goes against the Arduino incrementally build through trial and error.

Also be more clear when you say Discovery F4, there is a whole family of these boards. Try and indicate which chip is used. The one I have has a STM429 on it others have a ST401, ST407, or ST411. Using the Arduino model each of these is a separate variant and core, with some shared library code. There does not seem to be a one size fits all approach, like there is with AVR8.

Thanks for your help. I tried the whole weekend to get this thing running.
I use the STM32F407 Version of the discovery board and that is the code I use
int led1 = PD13;

void setup() {
// put your setup code here, to run once:
pinMode(led1, OUTPUT);
SerialUSB.begin();
}

void loop() {

digitalWrite(led1, HIGH); // turn the LED on (HIGH is the voltage level)
delay(1000); // wait for a second
//SerialUSB.write("0");
digitalWrite(led1, LOW); // turn the LED off by making the voltage LOW
delay(1000);

}


Which port are you physically connecting to your PC?

I dont think the USB port on the discovery F4 is a port that is normally connected to a PC, its a OTG (USB Host) port isnt it?

Yes, that is probably it ! The USB-OTG is connected to PB15/PB14 (and there is no 1K5 pullup)
I will have to figure out too for F429, probably tomorrow, hoping it is only pins defines that need to be change for OTG.

I think the F4 core (aka AeroQuad) has some code for USB host / OTG, but I’ve not investigated quite how to use it.

I’m pretty sure the USB port on the Disco F407 is not configured for USB Serial connection to a host, and its also not on the pins that libMaple normally uses for connections to a USB host

I guess its possible the the AeroQuad code may have serial USB running on PA11 and PA12 but that doesnt help us with the Disco F4 board hardware

AFAIK in Aeroquad the USB Port is implemented as a Virtual Comport USB Client.
It already registers as such with my code and the drivers from here
http://www.st.com/web/en/catalog/tools/PF257938
Problem is that I don´t receive any packets and rget an error 10 in the device manager after about 10 sec.

From what I can see from here
http://www.mobilerobots.pl/web_images/s … pinout.png
the USB is connected to PA9 and PA10

Are you guys using a different board ?

Thanks

Lucky1

The reason for the confusion is that we are using the AeroQuad core lib on the STM Discovery and Nucleo range of boards and AeroQuad board is wired / connected differently to the Discovery board.

We’d need to look at a schematic of the AeroQuad board to know what their core lib was intended to support in terms of how the hardware is connected.

I just checked the Pinout. It is PA11 and PA12 for the USB which is default
for the USB library. I think the Problem is in the Registers.
How do I set APB1 and APB2 appropriate ?

Lucky

The F1 familly is using PA9/PA10 pins for USB, but for F4 it is not the case.
The initialization code for USB under F4 is in the file Arduino_STM32/STM32F4/cores/maple/libmaple/usbF4/VCP/usb_bsp.c, which use PA11/PA12 for all F4 boards.
It is currently working fine for my Netduino2Plus and my STM32FStamp which both use STM32F405, the same pins as for F407.
BTW, the only differences between F405 and F407 is that F407 has also a additionnal Ethernet MAC interface.
(In my other case, for the F429 which has 2 ports, I will search how to use the second USB, the OTG-HS on PB15/PB14, by initializing it as an OTG-FS, but that is a completely different issue)
So, maybe in your case, the problem isn’t there.
Maybe it is an enumeration problem. Maybe it is a Windows driver issue.
We need to have more clues.

martinayotte wrote:The F1 familly is using PA9/PA10 pins for USB, but for F4 it is not the case.
The initialization code for USB under F4 is in the file Arduino_STM32/STM32F4/cores/maple/libmaple/usbF4/VCP/usb_bsp.c, which use PA11/PA12 for all F4 boards.
It is currently working fine for my Netduino2Plus and my STM32FStamp which both use STM32F405, the same pins as for F407.
BTW, the only differences between F405 and F407 is that F407 has also a additionnal Ethernet MAC interface.
(In my other case, for the F429 which has 2 ports, I will search how to use the second USB, the OTG-HS on PB15/PB14, by initializing it as an OTG-FS, but that is a completely different issue)
So, maybe in your case, the problem isn’t there.
Maybe it is an enumeration problem. Maybe it is a Windows driver issue.
We need to have more clues.

Martin

I will need to check if the F407 Discovery has the USB D+ pullup, as mine behaves as if it does not have that resistor.

RogerClark wrote:
I will need to check if the F407 Discovery has the USB D+ pullup, as mine behaves as if it does not have that resistor.

lucky1 wrote:
Could you please be so kind to check if my code is working on your Board and if it is, send me the binary file ?
I think that is the easiest way to see if the problem is on the board or on the PC.

martinayotte wrote:Although my Netduino2Plus has the LED on PC13, not PD13, it works. So I’ve re-compile it for you using PD13.

Sorry, I’m always forgetting, even for myself, when I switch back and forth between my STM32F4Stamp and Netduino (both F405, but as you said, Netduino is 25Mhz and Stamp is 8Mhz)

So, I’ve recompiled your sketch, after choosing explicitly Discover F407.

lucky1 wrote:
I tested your bin and device blinks but registers as “Unknown Device”

martinayotte wrote:
For this message, I’m almost sure that is the Windows driver for CDC.
I can’t help you much there, since I’m on Linux.

Your binary is working !!?? There seems to be a problem with my compiler or library.
I use latest 1.6.5 beta. I installed the Arduino SAM Board Library V1.6.4 and the Arduino STM32 library from github zip file.
I already checked 1.5.8. and it didn´t work also.I´m on Win7 64bit
What do you have installed? Is there a compiler setting I can try ?
Will install linux now and see if if I run into the same problem there.

Lucky1

Great ! That is a good news !
Personally, my stm32duino is under an old 1.6.1 with github unzipped months ago, but frequently merged with current github using “meld”.
I’ve also an 1.6.5 for my ESP stuff, but I’ve never installed stm32duino into this one.
Compiler settings are located in platform.txt which part of github.

I now have installed exactly the same versions of IDE and libraries under ubuntu in a virtual machine
Guess what, now the binaries are working. Since I use the same platform.txt for windows and linux
there is no difference. I have Windows 7 pro 64bit installed on a AMD CPU. Is there a compiler setting
or version I can try to make it work under Windows ?
At least now I have a workaround for my project work.

Lucky1

I don’t have much clues why there is differences in the 2 platforms.
You can try to diff the Arduino_STM32 tree, but I doubt you will find much.
Maybe the GCC is different since they are *.EXE, maybe there is bugs, but other people would have faced this earlier.

Sorry to reopen an older thread, but I’m encountering the same(ish) problem on my Windows 10 machine.

If I use the posted bin file, my F405 board comes up in Device Manager, and I see the ‘c’ character received once per second on the terminal program. So I’m sure the hardware seems to be working correctly.

When I compile the simple app (selecting either StampF405 or STM32F4Discovery board), the device shows up in Device Manager, but after 5 seconds I get the yellow exclamation point. The properties says:
“This device cannot start. (Code 10) {Device Timeout} The specified I/O operation on %hs was not completed before the time-out period expired.”
The blinking starts when I plug in the board. After a couple of seconds the blinking stops. Is whatever stopping the blinking possibly also stopping the board from talking over USB?

I’m using Arduino 1.6.5-r5. I’ve tried pretty much all the available versions of SAM. I’ve been using a several month old version of the STM library, but I also pulled down a new version today. I’ve also checked and the PLL_M variable in rccF2.c is set to 8 which matches the crystal on my board.

Sounds like W10 is not working out too well for you…

Ray
EX-MCSE

I don’t think it is windows 10 USB or driver issue. To summarize:
STMF405 board + binary posted earlier in thread + Windows 10 = working
STMF405 board + compiling source code posted earlier in thread + Windows 10 != working

If I find some spare time I’ll install the tools on my Debian machine.

anyone on a linux machine, tried lsusb following up with sudo lsusb -v -dnnnn:mmmm
does it show in the output or is there anything in the /var log files?

srp

I’ve tried to help dfwJones yesterday in some PMs, but I didn’t figure out. Probably as Lucky1 pointed out months ago, there is maybe a bug in the toolchain under Windows that maybe only pops up when using F4xx.
Yes, @dfwJones, if you got chance to try it on Debian, it will confirm the diagnostic done several month ago.

@zmemw16, I don’t know if it will help, but yes lsusb is producing output directly into the shell.
(it shows F407 even if I’ve F405, probably because it hard-coded into F4xxx USB code).

Bus 003 Device 007: ID 0483:5740 STMicroelectronics STM32F407
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
idVendor 0x0483 STMicroelectronics
idProduct 0x5740 STM32F407
bcdDevice 2.00
iManufacturer 1 STMicroelectronics
iProduct 2 STM32 Virtual ComPort in FS Mode
iSerial 3 00000000050C
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 67
bNumInterfaces 2
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xc0
Self Powered
MaxPower 100mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 2 Communications
bInterfaceSubClass 2 Abstract (modem)
bInterfaceProtocol 1 AT-commands (v.25ter)
iInterface 0
CDC Header:
bcdCDC 1.10
CDC Call Management:
bmCapabilities 0x00
bDataInterface 1
CDC ACM:
bmCapabilities 0x02
line coding and serial state
CDC Union:
bMasterInterface 0
bSlaveInterface 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82 EP 2 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0008 1x 8 bytes
bInterval 255
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 10 CDC Data
bInterfaceSubClass 0 Unused
bInterfaceProtocol 0
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x01 EP 1 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Device Status: 0x0001
Self Powered


I just finished a few new tests. I built the app on my Debian machine. I’m using Arduino 1.6.5, AVR library 1.6.9 and SAM library 1.6.6. I am also using the zip file I downloaded today of the STM32Duino library.

As before I selected the F407 Discovery board, even though I’m using a F405 board.

Guess what? It works fine. I get the repeating ‘c’ on my terminal app on the PC. The one thing I noticed was that when it works, the device shows up in Device Manager almost instantly. When it is not working, it takes about 10 seconds to appear, and about 5 more seconds before it stops.

So….. What is going on? I remember seeing a post in another forum a long time ago talking about a problem with VCP and that there was an issue of the starting address being out by 0x1000 (or something like that).

@martinayotte
just another data point, i thought if its not instantiating it might have yielded something in the log files
srp

@dfwJones, it is a bit unclear : is that you got it working on Linux but the Windows issue is still there ?

@zmemw16, I don’t understand your comment …

@martinayotte
When I build the code under Debian I get the VCP device to load and work under Windows 10.

When I build the code under Windows 10, the VCP device doesn’t load correctly and the blink only runs for a couple of seconds.

I wonder if any of the logging during the build process might give any clues? I’m attaching two files. One is the log for building on Debian and the other for building on Windows. Each file has two different builds, one using F405 Stamp and the other using F407Discovery.

So, it is quite the same issue as Lucky1 had. GCC under Linux works while GCC under Windows is producing bad binary.
It will be tough one to figure out exactly !
At least, in the means time, you have a workaround to let continue your project …

@dfwJones
what happens if you don’t run it as root?

stephen

@zmemw16
I gave up trying to get the Arduino suite to run when I’m not logged in as root.

Is there something that you think will be different when running root as opposed to when you are not? Do you think there would be a similar idea when running as a Windows user with admin rights?

when I’m not logged in as root
What do you means ?
Is it during the upload process that failed ?
In such case, you should edit the /etc/group and make sure your user is part of the “dialout” group.

@dfwJones
device permissions, permissions, ownership and ‘group’ of files get ignored.
as root you can do very nasty things by accident, simply a space inserted in the wrong command and you’ll have a blank hard drive. e.g. ‘rm -rf . / *’ ‘
there’s a reason it’s also known as ‘god mode!

there are many howto’s and faq’s about linux and arduino available.

a user having arduino problems says something is not setup properly, it may or may not be related.
quite probably it’s a udev rule or adding your user to a group.

i have a convenience bash scripts called ‘comms’ and ‘findols’ that i use, i almost always have my OLS board on /dev/ttyACM0
#!/bin/bash
ls -lt /dev |egrep 'ttyACM|ttyUSB'


I think we are getting off track with this permissions discussion. I have trouble believing that permissions on my Debian machine are the reason that the .bin file is different than the one created when I build on my Windows machine. If I’m using the same source file, the same version of Arduino, the same version of SAM and the same version of STM32Duino, I would hope that the .bin file would be the same.

I don’t have any problem transferring the either .bin file to my board. In fact I only upload from my Windows machine using the ST Demonstrator app.

As a separate thing I found today, the maximum flash size numbers are incorrect for the F407. My project is getting pretty big and it passed 110k and won’t compile unless I edit the boards.txt file.
#discovery_f407.upload.flash.maximum_size=108000
#discovery_f407.upload.maximum_size=108000
discovery_f407.upload.flash.maximum_size=1048576
discovery_f407.upload.maximum_size=1048576

Does anyone know why is was set to such a low value?

I suspect the flash size is a mistake caused, because the board file was created by copying and modifying another board file.

I cant update it now, but I will send myself an email and I will try to correct it in the next day or two.
Or create a PR just containing that change and I can action the PR directly on Github, which is the easiest thing for me to do.

RogerClark wrote:I suspect the flash size is a mistake caused, because the board file was created by copying and modifying another board file.

I cant update it now, but I will send myself an email and I will try to correct it in the next day or two.
Or create a PR just containing that change and I can action the PR directly on Github, which is the easiest thing for me to do.

Thanks

I’ve actioned the PR

Thanks for making the change. I’m now wondering if it is the correct one?
For the STM32F407xE parts, the flash size is 512K, for the STM32F407xG parts the flash size is 1024K.

The STM32F4Discovery board is using a G part, so your change would be ok. If someone wants to build for one of the E parts they’d need to edit the boards.txt file for the smaller size. Could a comment be put in the boards.txt file?

dfwJones wrote:Thanks for making the change. I’m now wondering if it is the correct one?
For the STM32F407xE parts, the flash size is 512K, for the STM32F407xG parts the flash size is 1024K.

The STM32F4Discovery board is using a G part, so your change would be ok. If someone wants to build for one of the E parts they’d need to edit the boards.txt file for the smaller size. Could a comment be put in the boards.txt file?

martinayotte wrote:
@zmemw16, I don’t know if it will help, but yes lsusb is producing output directly into the shell.
(it shows F407 even if I’ve F405, probably because it hard-coded into F4xxx USB code).

bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0


Hi Thomas

We need help with USB on the new HALMX core.

Do you have experience with developing USB code ?

I am not sure if you have a F103 or F4 board. I presume you have an F4 as you posted to this thread?

RogerClark wrote:Hi Thomas

We need help with USB on the new HALMX core.

Do you have experience with developing USB code ?

I am not sure if you have a F103 or F4 board. I presume you have an F4 as you posted to this thread?

Hi Thomas

I think you have more experience in USB than most if the rest of us

with this specific issue on the F4, you could try changing that value in the USB descriptor, and see if the USB still works.

We often find mistakes in the code, where things still work, even then stuff is done wrong.

But its best to fix these anomalies, as sooner or later the code will not work on some specific hardware / PC combination.

GrumpyOldPizza wrote:
Not sure anybody answered that one before, bDeviceClass is wrong for a non-composite CDC/ACM device. bDeviceClass should be 2. Windows chokes on the 0 value, as it does if you have the IAD as the first element …

martinayotte wrote:GrumpyOldPizza wrote:
Not sure anybody answered that one before, bDeviceClass is wrong for a non-composite CDC/ACM device. bDeviceClass should be 2. Windows chokes on the 0 value, as it does if you have the IAD as the first element …

Of course, under Windows there is no such ways to do a “tail -n 1000 /var/log/bill*.log” or “tail -n 1000 /var/log/balmer*.log” …

(Slap on my finguers : they gave me paycheck during almost 4 years in late 199x )

It may be possible to fool Windoze by editing the .inf; for example, I used this trick a year ago to recover from a bad FTDI:
https://ljck.org/unbrick_ftdi

Last Winter, I bought a one-way ticket for my lab Acer.. from W8.1 to Linux Mint 17.3
There is no return to Winland.

Ray