is the usb port already supported by the library ?
Regards
Lucky1
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 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.
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);
}
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?
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’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
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
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.
for the USB library. I think the Problem is in the Registers.
How do I set APB1 and APB2 appropriate ?
Lucky
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.
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.
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.
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.
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.
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”
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.
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
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.
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
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.
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.
Ray
EX-MCSE
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.
does it show in the output or is there anything in the /var log files?
srp
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
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).
just another data point, i thought if its not instantiating it might have yielded something in the log files
srp
@zmemw16, I don’t understand your comment …
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.

It will be tough one to figure out exactly !

At least, in the means time, you have a workaround to let continue your project …

what happens if you don’t run it as root?
stephen
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?
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.
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 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 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.
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.
I’ve actioned the PR
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?
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?
@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
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?
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?
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.
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 …
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 …

(Slap on my finguers : they gave me paycheck during almost 4 years in late 199x )
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