I purchased a STM32F4 Discovery quite recently, and when I initially unboxed the board, I hooked it up to my Mac, and the already programmed in demonstration was working 100%. I was able to view the flashing LEDs, and when pressing the user button, the accelerometer would act as a mouse pointer controller, moving the mouse pointer about on the screen as I tilted the board.

STM32F4 Discovery evaluation board

I used Texane ST-Link and the Sourcery Codebench Lite toolchain to compile a few other examples, nothing serious, just basic blinky stuff, and everything was working fine when flashing the board.

It took me a couple of weeks to get Eclipse CDT setup with the toolchain, it's quite a tedious process. I downloaded the samples from ST.com compile the original Demonstration from the STM32F4 Discovery board page. The compilation now works fine, I am able to build without errors, but when I flash the board with the compiled binary, everything seems to work fine.

The LED blinky bit works fine, and when I press the user button, once again, the board goes into the accelerometer mode. The lights are flashing as the board is tilted, but this time the mouse pointer interaction stopped, the mouse pointer is not moving at all.

I tried checking if my USB cable was borked, tried a different cable, and I also tried another machine, but no matter what I tried, I couldn't get the board to work as a USB device using the original demo.

Is there some way I can get the original .hex files to flash the board, to see at least if it works in the way it comes out of the box. I'm guessing if I can ask whether I can reset the board to factory standard, with the original demonstration. This way I can eliminate the possibility of whether the USB pins on the board might have blown or something is wrong with my toolchain.

New info

I gathered my guts to try and run the application in debug mode again, set a breakpoint where the HID report is being sent. The code calls USBD_HID_SendReport, but, as per the image below, the if (pdev->dev.device_status == USB_OTG_CONFIGURED) block never executes, the function just returns USBD_OK

enter image description here

Looking at pdev->dev.device_status a bit deeper, reveals the following:

enter image description here

The device status is 1, which matches USB_OTG_DEFAULT, which is one value of four, defined together amongst:

#define USB_OTG_DEFAULT    1

Does this mean anything to anyone? I'm not too much of a guru here.

  • \$\begingroup\$ I forget how to get a list of attached USB peripherals on a Mac (system report advanced or something like that) but it would be worth checking to see if it is recognized and listed as an HID mouse. \$\endgroup\$ Commented Mar 24, 2013 at 15:14
  • \$\begingroup\$ It looks like it's not even enumerating (which would end up with the configured status) On windows, you usually get a sound that indicates there is a problem with enumeration (i.e. if something is detected but fails to enumerate) I'm not sure what happens on Macs, but I'd think it would be similar, so maybe it's not even being detected. Still, as Chris suggests, checking to see if anything is listed in the peripherals is worth a shot (may indicate some faulty status there) \$\endgroup\$
    – Oli Glaser
    Commented Mar 24, 2013 at 20:31

1 Answer 1


I also have the Discovery board but only used it with Windows and the Raisonance toolchain (after a brief mess around with the Atollic IDE and embedded ST-Link). However, it doesn't sound to me like it's a compile/platform issue if everything else in the demo is working okay. You could try going back to your original setup to confirm this though.
One thing I did notice whilst using it was the USB connector is quite delicate (I have had to resolder a couple of USB mini/micro connectors on my own prototypes a couple of times after repeated use)

So my guess is from your description, it sounds like it's quite possibly a bad solder joint on the (micro) USB connector - try testing the continuity on all the pins. It will be hard to get a probe on there, so plug a cable in and probe at the A connector side (you may need to wrap some thin wire round your probe tip, or break the cable), with the other probe on either one of the STM32F4 USB pins, or a power/ground point (look in the User manual, it has a schematic)
If you have a scope, probe the USB pins to see if there is some activity on there (even if the scopes bandwidth isn't capable you should be able to see some activity)

  • \$\begingroup\$ Is there a slight possibility I can send you the binaries to try it on your discovery? \$\endgroup\$ Commented Mar 24, 2013 at 13:54
  • \$\begingroup\$ @josef.van.niekerk - yes, send them to the email in my profile. I'll do my best to look at them later when I have a spare half hour or so (sometime tonight, UK time) \$\endgroup\$
    – Oli Glaser
    Commented Mar 24, 2013 at 13:58
  • \$\begingroup\$ Thanks Oli! I'm testing the pins now, but it's as you said, darn tricky getting the probe in there. \$\endgroup\$ Commented Mar 24, 2013 at 14:00
  • \$\begingroup\$ Not if it's a very low resistance (e.g. < 10 Ohms), no. Usually (and according to the schematic in the user manual - pg.34) the connector shield is tied to GND (pin 5 in the Micro AB) This does sound unlikely though as if you had a short something (either the programmer or the PC) should complain about overcurrent/voltage problems, and the demo wouldn't work at all, so double check thoroughly. \$\endgroup\$
    – Oli Glaser
    Commented Mar 24, 2013 at 14:45
  • \$\begingroup\$ Pluggin the CN5 USB cable, the power light comes on, so at least I know the Vusb and GND pins are ok. \$\endgroup\$ Commented Mar 24, 2013 at 15:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.