Mountaineer USB - This device cannot start. (Code 10)

Archive
21

@ Gene

Does the green LED blink in spite of the exception?

Cuno

22

I’ve tried your code. It doesn’t work on my Mountaineer Ethernet aswell.

Which pin is the (Cpu.Pin)75 ?

Do you want to control the Mainboard LED?

Have you tried


Mainboard.SetDebugLED(True);
Mainboard.SetDebugLED(false);

?

23

Can you try it without the “using Mountaineer.Gadgeteer” declaration, and after also removing [em]all [/em] references to Gadgeteer libraries from the Visual Studio project?

24

It is the green LED of the mainboard’s RGB LED.

See also “User LED” in http://www.mountaineer.org/app/download/7038536775/Mainboard+Mainboard+Sockets+V20130108.png?t=1357643442

Cuno

25

Never mind, I was so befuddled by my other issues, the code I posted is completely wrong. I’m working on something more reasonable now.

26

Whoo, hoo!!

As Cuno suggested, I took out all references and usings that had Gadgeteer in them and I can blink the LED on the Mountaineer board! The only references are .SPOT.Hardware, .SPOT.Native and mscorlib.

I attached an image of what my VS project looks like.

Below is what shows up in the Output window. Toward the bottom, there is a line that reads “The thread ‘’ (0x2) has exited with code 0 (0x0).”. I never noticed this before but my program works so I’m assuming it is a non-issue.

Many, many thanks to everyone who helped me with this issue. If you’re ever in the Monterey Bay, CA area, give me a call at the Monterey Bay Aquarium Research Institute and I’ll give you a tour. We have some pretty cool stuff going on.

Cheers - Gene

[em]Found debugger!

Create TS.

Loading start at 8045758, end 80589dc

Assembly: mscorlib (4.2.0.0) Assembly: Microsoft.SPOT.Native (4.2.0.0) Assembly: Microsoft.SPOT.Hardware (4.2.0.0)
Assembly: Microsoft.SPOT.Hardware.SerialPort (4.2.0.0) Assembly: Microsoft.SPOT.Hardware.Usb (4.2.0.0)
Assembly: Microsoft.SPOT.Hardware.PWM (4.2.0.1) Assembly: System.Xml (4.2.0.0)
Loading Deployment Assemblies.

Attaching deployed file.

Assembly: MountaineerDigitalIO (1.0.0.0) Resolving.

The debugging target runtime is loading the application assemblies and starting execution.
Ready.

‘Microsoft.SPOT.Debugger.CorDebug.dll’ (Managed): Loaded ‘C:\Program Files\Microsoft .NET Micro Framework\v4.2\Assemblies\le\mscorlib.dll’, Symbols loaded.
‘Microsoft.SPOT.Debugger.CorDebug.dll’ (Managed): Loaded ‘C:\Program Files\Microsoft .NET Micro Framework\v4.2\Assemblies\le\Microsoft.SPOT.Native.dll’, Symbols loaded.
‘Microsoft.SPOT.Debugger.CorDebug.dll’ (Managed): Loaded ‘C:\Program Files\Microsoft .NET Micro Framework\v4.2\Assemblies\le\Microsoft.SPOT.Hardware.dll’, Symbols loaded.
‘Microsoft.SPOT.Debugger.CorDebug.dll’ (Managed): Loaded ‘C:\Program Files\Microsoft .NET Micro Framework\v4.2\Assemblies\le\Microsoft.SPOT.Hardware.SerialPort.dll’, Symbols loaded.
‘Microsoft.SPOT.Debugger.CorDebug.dll’ (Managed): Loaded ‘C:\Program Files\Microsoft .NET Micro Framework\v4.2\Assemblies\le\Microsoft.SPOT.Hardware.Usb.dll’, Symbols loaded.
‘Microsoft.SPOT.Debugger.CorDebug.dll’ (Managed): Loaded ‘C:\Program Files\Microsoft .NET Micro Framework\v4.2\Assemblies\le\Microsoft.SPOT.Hardware.PWM.dll’, Symbols loaded.
‘Microsoft.SPOT.Debugger.CorDebug.dll’ (Managed): Loaded ‘C:\Program Files\Microsoft .NET Micro Framework\v4.2\Assemblies\le\System.Xml.dll’, Symbols loaded.
‘Microsoft.SPOT.Debugger.CorDebug.dll’ (Managed): Loaded ‘C:\Users\magene\Documents\Visual Studio 2010\Projects\MountaineerDigitalIO\MountaineerDigitalIO\bin\Debug\le\MountaineerDigitalIO.exe’, Symbols loaded.
The thread ‘’ (0x2) has exited with code 0 (0x0).

Starting Program …

The program ‘[16] Micro Framework application: Managed’ has exited with code 0 (0x0).[/em]

27

Very interesting to see what kind of projects you are doing there!

28

I am working with a custom board very similar to the Mountaineer Eth, i. e., based on the same STM32F407VGT6, and am seeing an error that looks similar to the one described by the original poster.

[ul]Pulling up BOOT0, it enters DFU mode alright, and I can use the DfuSe Demonstrator tool to flash the Mountaineer 4.2 QFE2 firmware image via USB.[/ul]
[ul]Outside DFU mode though, it shows as “Mountaineer ETH” with a yellow warning sign in the Device manager, and the status is[/ul]

[ul]pulling up PE10 (= SW on Mountaineer) when starting the board, I can see PE14 (= blue LED on Mountaineer) flash, which I take as proof that TinyBooter entered upload mode. On the Windows side, the Device Manager shows the same error entry as above.[/ul]
[ul]MFDeploy does not see the device in either start mode.[/ul]

OS is Windows 7 x64, tried on two different PCs. The board has a separate power supply and draws no power from the USB VBUS pin. On the same PCs, the genuine Mountaineer board is shown without error in the Device Manager, and is seen by MFDeploy.

I would be very glad to get any hints in which direction I could look for the error source. Thanks a lot in advance!

29

Your issue is the driver not starting - although I don’t understand why the same driver is trying to start when in tinybooter mode (but that could be expected, it wasn’t my expectation though).

So I think if we can find a reason for driver not to start and can resolve that, we’ll make progress. Can you do screenshots of the driver info tabs from Device Manager and attach here? I seem to remember some specific guidance from Mountaineer about driver loading - have you (found and) followed their advice?

30

Thanks for the reply.

See below (only a few properties displayed - which ones would be interesting?)

I guess you mean this:
http://www.mountaineer.org/app/download/6122023375/Mountaineer+Firmware+and+USB+Driver+Installation+Guide+for+NETMF+4.2+QFE2+V20120921.pdf

Which is what I did.
The only detail which I did differently than described is that I did not check “verify after download” in the DfuSE tool, because this option reproducably leads to crashes of the tool. I do not think that verify is crucial, though, as the genuine Mountaineer board works nevertheless, and the blinking LED in TinyBooter shows that at least this part must have been written to flash alright…

31

I think you got the important ones - especially the WinUSB “service” page. My only thoughts are can you do step 6 from the install PDF you linked to again (I know, you did it before… I’m exceeding my knowledge here and this is about the only thing that makes sense). Then I’d also make sure you did step 7 again… it says it might get confused if you don’t.

32

I know this is probably obvious, but since you mentioned it’s a custom board, did you check your hardware? Specifically, your crystal configuration? DFU mode auto-detects your HSE crystal frequency, but if you flash the stock firmware on the device, TinyBooter and TinyCLR both expect a 12 MHz crystal.

If TinyBooter or TinyCLR hang after enumeration, it will usually instead cause a “Windows has stopped this device” error.

Typically, if you’re building a custom board, you should always put accessible JTAG/SWD headers on the first revision. With an SWD interface, you’d be able to immediately see what’s going on. There’s a lot of software and hardware that sit between your board and your computer’s USB interface. If anything goes wrong, it all fails.

1 Like
33

You hit the bull’s eye. As it turns out, we have an 8 MHz crystal. I guess there is no way to change the frequency setting of TinyCLR without rebuilding it? I will try and replace the crystal…

I actually have a full JTAG header which we use to program/debug with the CooCox IDE (non-netmf). That works without problems on this board, but I have not tried to debug TinyBooter or TinyCLR with it. I suspect I would have to build netmf myself for that, which is something I shied away from so far…

34

Just did that, and bang! Problem solved.

Thanks again for the hint, jay!