2017-02-08 06:07 PM
Hi all,
I am currently trying to get USB OTG FS working with STM32F412/411 MCUs in device mode but unfortunately the PC doesn't recognize the device. Cannot figure out if it is a hardware or software problem because I do not have a proper code which is proven to be working on STM32F412/411. STMCubeMx generated code for USB_FS_OTG_Device mode also doesn't work for any of STM32 MCUs (tested on STM32F429IIT6, STM32F412/411). I do have a working application for STM32F429IIT6 in USB_OTG_HS_Device mode but this code doesn't work for STM32F412/411 after modifications to USB pins and clocks even though the USB OTG circuit is similar in both cases. The USB Analyzer shows that the device doesn't respond to the packets sent by the Host. Please find attached the USB analyzer screenshots of working USB device on STM32F429IIT6 and not-working USB device on STM32F412. Could someone share a working USB OTG FS Device mode code for STM32F412/411 please or anyone who had the same problem and found a solution please share your ideas. Thanks!
2017-02-10 01:19 AM
Hi
ndona
,In the
, you find USB device axamples for the devices you selected in the following paths:-Amel
To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.
2017-02-12 10:06 PM
Hi Amel,
Thanks for your reply. I have already tried these examples and they are not working on my design.
Does anyone know if there is a way to probe 48MHz USB clock just to make sure if it is setup properly?
Thanks!
Nalika.
2017-02-13 02:08 PM
Looking at the clock tree. Not obvious how to probe.
Okay I'm just quickly passing by and not real familiar with this part but -
You are NOT using a demo board?
You have your own HARDWARE already designed?
Your porting over an HS app to a FS app?
When you plug in, the PC sends SOMETHING. meaning you must have D+ or D- pulled up. (PC saw 'something')
Presumably you have a P/U resistor on one of those lines or you are using VBUS detect. Which?
HSE crystal is?
I2S clock is ?
Which PLL are you using
M,N P,R,Q settings?
2017-02-13 08:07 PM
Hi shingadaddy,
Thanks for your reply and here are the answers for your questions.
I am NOT using a demo board and have my hardware already designed.
I have tried ''porting over an HS app to a FS app'' and I gave up as it didn't work. I'm currently trying the application at ''STM32Cube_FW_F4_V1.14.0\Projects\STM32F412G-Discovery\Applications\USB_Device'' because it is the same chip ''STM32F412'' but I had to change the clock configuration and the USB pins configuration.
I haven't pulled up D+ or D-, neither in software or in hardware and I am using v_bus sensing as in the code it says ''hpcd.Init.vbus_sensing_enable = 1;''
HSE crystal is 16MHz.
I don't think I'm using I2S clock.
Please find the code images with PLL clock configuration, USB pin configuration and the hardware design.
These are the only changes I've made to the example code available at above link.
Thanks very much for your support.!
Nalika.
2017-02-14 12:37 AM
Did you tried generating code using CubeMX? It helps you to make the easily the clock configuration you want and which is suitable for USB usage.
-Amel
To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.
2017-02-14 12:58 PM
The numbers I see here seem okay as far as NUMBER MATH. Make sure that these numbers are within the range of acceptable numbers for your specific part for each setting. I am pretty sure I've seen complaints of CubeMX generating numbers that were GOOD NUMBERS generally but BAD numbers for specific part capabilities.
Don't know if that's been fixed. Try a few combinations that are within the spec but *other* than THESE numbers and see if that helps. Just so long as your math lands on 48Mhz. According to the TREE in the UM your okay with 16Mhz, /8 (/2 to /63) , *192 (50 to 432) , /8 (2 to 15)
You must be doing SOMETHING because your VBUS detect must be working and yanking up the D+ (or D-) line since your analyzer saw traffic from PC to device. (PC knows you plugged SOMETHING on)
Um.... Make sure it is yanking up the D+ line for FS and that you don't have the D- getting yanked up by a line swap, which puts the bus speed off in the weeds....
Blinking LED in your LOOP?
All I see seems okay. The LINE swap has bit me before and acts exactly like you are seeing. This quickly comes to your PORT OVER effort.
Did I mention a blinking LED in your loop?
One of the things I have also been bit on was an I/O expander on one demo board (EVAL)where I swiped example code from where the demo app expected communication via I2C or SPI and the board I port to (NUCLEO) didn't have this little trouble maker. No talk = NO RUN. Look out for that sneaky stuff.
2017-02-15 01:54 PM
'Sneaky stuff' - I just looked and that DISCOVERY eval board apparently comes with an LCD. There's a good chance that the CUBE eval software
'STM32Cube_FW_F4_V1.14.0\Projects\STM32F412G-Discovery\Applications\USB_Device' -- AS IS --
probably tries to do some clever stuff with this LCD when it powers up and that means the micro tries to talk to that LCD. And probably expects something BACK from the LCD. If you have no LCD then it doesn't get what it expects and might trigger the infamous ERROR HANDLER FOREVER WHILE LOOP trick I see in some places in the ST stuff. Much like the I/O expander I mentioned. Worth a look maybe ? Let us know how its going.
2017-02-16 08:13 PM
Hi Amel,
I tried by generating code using CubeMX version 4.18.0. But any of the codes didn't work for my design and even for STM32F429 board. It didn't work for STm32F407 discovery board as well, so I gave up proceeding with cube generated applications. :)
-Nalika.
2017-02-16 08:53 PM