Skip to main content
Nalika Dona
Associate
February 9, 2017
Question

USb OTG FS Device Mode with STM32F412/411

  • February 9, 2017
  • 13 replies
  • 5397 views
Posted on February 09, 2017 at 03:07

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!

    This topic has been closed for replies.

    13 replies

    Amel NASRI
    ST Technical Moderator
    February 10, 2017
    Posted on February 10, 2017 at 10:19

    Hi

    ndona

    ‌,

    In the

    http://www.st.com/content/st_com/en/products/embedded-software/mcus-embedded-software/stm32-embedded-software/stm32cube-embedded-software/stm32cubef4.html

    , you find USB device axamples for the devices you selected in the following paths:

    • STM32Cube_FW_F4_V1.0\Projects\STM32F412G-Discovery\Applications\USB_Device
    • STM32Cube_FW_F4_V1.0\Projects\STM32F412ZG-Nucleo\Applications\USB_Device

    -Amel

    To give better visibility on the answered topics, please click on "Best Answer" on the reply which solved your issue or answered your question.
    Nalika Dona
    Associate
    February 13, 2017
    Posted on February 13, 2017 at 06:06

    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.

    Amel NASRI
    ST Technical Moderator
    February 14, 2017
    Posted on February 14, 2017 at 08:37

    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 "Best Answer" on the reply which solved your issue or answered your question.
    shingadaddy
    Senior
    February 13, 2017
    Posted on February 13, 2017 at 23:08

    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?

    Nalika Dona
    Associate
    February 14, 2017
    Posted on February 14, 2017 at 04:07

    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.0690X00000603ZxQAI.jpg0690X00000603clQAA.jpg0690X00000603cvQAA.jpg0690X00000603dZQAQ.jpg

    shingadaddy
    Senior
    February 14, 2017
    Posted on February 14, 2017 at 21:58

    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.

    shingadaddy
    Senior
    February 15, 2017
    Posted on February 15, 2017 at 22:54

    '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.

    Nalika Dona
    Associate
    February 17, 2017
    146787CGIL2
    shingadaddy
    Senior
    February 21, 2017
    Posted on February 21, 2017 at 18:37

    Limited time/resources here prevent me from loading up yet ANOTHER IDE (other than Truestudio - which there are NO PRE SUPPLIED examples for this F4 USB thing in a Truestudio project anyway - ) will limit my help to the following:

    Well the only QUICK paths to supposedly workable 'example code' offerings are

    CUBEMX  - Auto generate SOME level of functionality

    or

    CUBEF4 - precanned HID and MSC device examples in the Discovery F4 CubeF4 offering.

    But I'm not familiar with their level of BUGGINESS.

    As far as the CUBEF4 offering -

    I realize you have your own board (Unknown feasibility / functionality level) and as a quick confidence test, you would be trying to run code on it, that is targeted toward a DISCOVERY board.You have no Discovery board but that's where the CUBEF4 examples want to run on. I make the ASSUMPTION that the DISCOVER F4 example code EXPECTS an LCD to be there. Your LED might blink but without finding all the LCD communication functionality that is EXPECTED by the CUBEF4 example code, and making sure it's commented out to keep it from putting on a parachute and bailing out of ALL the rest of the example code functionality - including some of the USB stuff -  your USB stuff may be non-functional at some level. And - THERE MAY BE MORE THAN JUST THAT which needs attention (commenting around/out) along with the LCD stuff. I mentioned the LCD before but you make no mention of how you might have approached that. In MAIN - I see you commented out     GetPointerData(HID_Buffer);

    But this application example relies heavily on Interrupt routines so other calls to other LCD functions might be causing issues. I don't have time to look that deep.

    An I/O expander derailed me on a different project that was similar to this while I was using precanned example programs that EXPECTED and I/O expander that I did not have on my PCB.

    You make no mention of DEBUGGER so I ASSUME you have no way to use one. (STLINK)

    AS far as CUBEMX -

    Sorry your on your own there. No familiarity here what so ever.

    Tuttle.Darrell
    Associate II
    February 21, 2017
    Posted on February 21, 2017 at 20:00

    How about trying System Memory Boot Mode (BOOT0 high) and seeing if the PC recognizes the ST DFU Bootloader? This should tell you if your hardware is working.

    shingadaddy
    Senior
    February 21, 2017
    Posted on February 21, 2017 at 20:19

    Good one Tut. I hadn't looked to see if this part had DFU built in. I suspect it would mean you need to have the DFU driver from ST installed maybe. Then the PC should recognize it as a USB device in DFU mode.

    And if that doesn't work right, the way things are around here with purchasing, receiving, inspection, kitting, assembing interactions, you might want to make sure R9 and 10 are REALLY the values that you REALLY wanted.

    Also you might want to make sure R9 and 10 are really needed for this part. Variation of ST devices sort of mingle in and out of that need. Some are BUILT IN.

    Tuttle.Darrell
    Associate II
    February 21, 2017
    Posted on February 21, 2017 at 20:32

    Even without the driver, if working it will show up in Device Manager as something like 'ST Micro DFU Bootloader', but it will not go into DFU mode without the driver so will not be recognizable by DfuSeDemo. And yes, the STM32F412 includes the FS DFU bootloader in system memory boot mode.