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.
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
Looking at pdev->dev.device_status a bit deeper, reveals the following:
The device status is 1, which matches USB_OTG_DEFAULT, which is one value of four, defined together amongst:
#define USB_OTG_DEFAULT 1
#define USB_OTG_ADDRESSED 2
#define USB_OTG_CONFIGURED 3
#define USB_OTG_SUSPENDED 4
Does this mean anything to anyone? I'm not too much of a guru here.
Best Answer
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)