# STM32F4 Discovery demonstation not working anymore

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_CONFIGURED 3
#define USB_OTG_SUSPENDED  4


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

• 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. – Chris Stratton Mar 24 '13 at 15:14
• 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) – Oli Glaser Mar 24 '13 at 20:31