cancel
Showing results for 
Search instead for 
Did you mean: 

Broken STM32F4 Discovery demonstration...no mouse!

josef
Associate II
Posted on March 24, 2013 at 18:01

I quite enthusiastically purchased an 

http://www.st.com/web/en/catalog/tools/PF252419

 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. That was awesome!

I used 

https://github.com/texane/stlink

 and the 

http://www.mentor.com/embedded-software/sourcery-tools/sourcery-codebench/editions/lite-edition/

 toolchain on Mac OS X 10.8 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 CodeBench toolchain, it's quite a tedious process, but at least I'm compiling without errors now.

I downloaded the samples from ST.com trying to compile the original Demonstration from the STM32F4 Discovery board page. The project compiled without errors, and when I flashed the board with the compiled binary, everything seemed to work fine.

The LED blinking bit works okay, 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. The green LED next to the CN5 connector is coming on, indicating power, and I even tested with a multimeter, it's a good 5V+.

Is there some way I can get the original .elf 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.

I have created a

https://github.com/josefvanniekerk/stm32f4-discovery

 where I've setup the

https://github.com/josefvanniekerk/stm32f4-discovery/tree/master/projects/demonstration

 to compile with Eclipse Juno CDT, the GNU ARM Eclipse plugin, Sourcery Codebench Lite, see the

https://github.com/josefvanniekerk/stm32f4-discovery/blob/master/readme.md

for more details.

I also added my

https://github.com/josefvanniekerk/stm32f4-discovery/tree/master/projects/demonstration/debug

, and was hoping maybe someone could flash their Discovery and see if the example works with mouse pointer moving on the accelerometer.

#stm32f4-discovery-usb-demonstrat
1 REPLY 1
josef
Associate II
Posted on March 24, 2013 at 18:16

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*

0690X00000605UjQAI.png

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

0690X00000605UtQAI.png

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.