Panda II only works in debug mode

Archive
21

What version of VS are you using? I can’t recall whether there was a VS version change that may have occurred before you started having this issue or not?

I have just identified something that I didn’t expect to see (and a behaviour that I didn’t think occurred). In the blink-LED scenario, if I disconnect debugger from MFDeploy, my app actually stopped mid-process (so the LED stopped blinking) and resetting the board but having it connected to the PC without the debugger attached means it doesn’t start. As soon as I attach the debugger, the LED flash starts. If I power the device separately, the app starts as I would expect, starting LED flash almost immediately. I wonder if this is related to the WinUSB driver change?

Edit: and this could actually match your original problem statement, but I think I thought when you said “debug mode” you meant setting the netmf project properties away from “release” mode to “debug” mode, not whether you physically had a debugger attached to the board or not.

22

@ NickS I have tried both adding a blinking function to my existing code and running a bare minimum, just blink an LED function.

@ Brett both my SDK and firmware are version 4.1.8. this is the output I got from MFDeploy

Rebooting…
Create TS.
Done.
Loading start at 4eb34, end 56d0c
Attaching file.
Assembly: mscorlib (4.1.2821.0) (3880 RAM - 33236 ROM - 19134 METADATA)
AssemblyRef = 0 bytes ( 0 elements)
TypeRef = 0 bytes ( 0 elements)
FieldRef = 0 bytes ( 0 elements)
MethodRef = 0 bytes ( 0 elements)
TypeDef = 1112 bytes ( 139 elements)
FieldDef = 272 bytes ( 135 elements)
MethodDef = 1572 bytes ( 786 elements)

Attributes = 0 bytes ( 0 elements)
TypeSpec = 16 bytes ( 4 elements)
Resources = 232 bytes ( 29 elements)
Resources Files = 16 bytes ( 2 elements)
Resources Data = 437 bytes
Strings = 1551 bytes
Signatures = 2126 bytes
ByteCode = 11702 bytes

Loading Deployment Assemblies.
Attaching deployed file.
Assembly: FEZPanda_II_GHIElectronics.NETMF.FEZ (4.1.8.0) (304 RAM - 904 ROM - 495 METADATA)
AssemblyRef = 12 bytes ( 3 elements)
TypeRef = 44 bytes ( 11 elements)
FieldRef = 0 bytes ( 0 elements)
MethodRef = 20 bytes ( 5 elements)
TypeDef = 72 bytes ( 9 elements)
FieldDef = 12 bytes ( 6 elements)
MethodDef = 4 bytes ( 2 elements)

Attributes = 0 bytes ( 0 elements)
TypeSpec = 0 bytes ( 0 elements)
Resources = 0 bytes ( 0 elements)
Resources Files = 0 bytes ( 0 elements)
Resources Data = 0 bytes
Strings = 182 bytes
Signatures = 35 bytes
ByteCode = 98 bytes

Attaching deployed file.
Assembly: Microsoft.SPOT.Hardware (4.1.2821.0) (1752 RAM - 11440 ROM - 7371 METADATA)
AssemblyRef = 8 bytes ( 2 elements)
TypeRef = 124 bytes ( 31 elements)
FieldRef = 24 bytes ( 6 elements)
MethodRef = 120 bytes ( 30 elements)
TypeDef = 496 bytes ( 62 elements)
FieldDef = 176 bytes ( 88 elements)
MethodDef = 444 bytes ( 222 elements)

Attributes = 0 bytes ( 0 elements)
TypeSpec = 0 bytes ( 0 elements)
Resources = 0 bytes ( 0 elements)
Resources Files = 0 bytes ( 0 elements)
Resources Data = 0 bytes
Strings = 1329 bytes
Signatures = 1067 bytes
ByteCode = 2611 bytes

Attaching deployed file.
Assembly: FEZ Panda II Application (1.0.0.0) (284 RAM - 920 ROM - 444 METADATA)
AssemblyRef = 12 bytes ( 3 elements)
TypeRef = 52 bytes ( 13 elements)
FieldRef = 0 bytes ( 0 elements)
MethodRef = 36 bytes ( 9 elements)
TypeDef = 24 bytes ( 3 elements)
FieldDef = 4 bytes ( 2 elements)
MethodDef = 12 bytes ( 5 elements)

Attributes = 0 bytes ( 0 elements)
TypeSpec = 0 bytes ( 0 elements)
Resources = 16 bytes ( 2 elements)
Resources Files = 8 bytes ( 1 elements)
Resources Data = 13 bytes
Strings = 165 bytes
Signatures = 64 bytes
ByteCode = 127 bytes

Attaching deployed file.
Assembly: Microsoft.SPOT.Native (4.1.2821.0) (1144 RAM - 6516 ROM - 4479 METADATA)
AssemblyRef = 4 bytes ( 1 elements)
TypeRef = 80 bytes ( 20 elements)
FieldRef = 0 bytes ( 0 elements)
MethodRef = 60 bytes ( 15 elements)
TypeDef = 336 bytes ( 42 elements)
FieldDef = 192 bytes ( 95 elements)
MethodDef = 224 bytes ( 111 elements)

Attributes = 48 bytes ( 6 elements)
TypeSpec = 0 bytes ( 0 elements)
Resources = 72 bytes ( 9 elements)
Resources Files = 8 bytes ( 1 elements)
Resources Data = 747 bytes
Strings = 648 bytes
Signatures = 595 bytes
ByteCode = 418 bytes

Resolving.

Total: (6228 RAM - 53016 ROM - 31923 METADATA)
AssemblyRef = 36 bytes ( 9 elements)
TypeRef = 300 bytes ( 75 elements)
FieldRef = 24 bytes ( 6 elements)
MethodRef = 236 bytes ( 59 elements)
TypeDef = 2040 bytes ( 255 elements)
FieldDef = 656 bytes ( 326 elements)
MethodDef = 2256 bytes ( 1126 elements)

DebuggingInfo = 1136 bytes

Attributes = 48 bytes ( 6 elements)
TypeSpec = 16 bytes ( 4 elements)
Resources Files = 96 bytes ( 4 elements)
Resources = 320 bytes ( 40 elements)
Resources Data = 1197 bytes
Strings = 3875 bytes
Signatures = 3887 bytes
ByteCode = 14956 bytes

Ready.
.
+
.
+

23

yes that sounds like the problem I am having, but i do not know if it will run if i connect to a power supply other than a PC because I do not have something else to hook it up to right now.

24

I can reproduce the behaviour with VS2010. I will test with an older sdk virtual machine to see if its related to the driver.

25

So the simple workaround at the moment is to open MFDeploy and connect to it. This will mean the debugger attaches to the board and it continues to tick along as you’d expect.

I am beginning to think that this must be related to the device driver change, the board/driver establish that a debug channel can exist and the board won’t start unless the debug is active. @ GHI, any thoughts on if this makes sense at all? I know the actual Panda firmware won’t have changed but the logic of the driver has. I can repro this simply - attach with MFDeploy, app starts running; disconnect with Ctrl-F5 and the app stops; F5 again and the app keeps running; Ctrl-F5 and it stops. Even under VS, disconnecting the debugger stops the app. This doesn’t repro on 4.2 (only tested on a Cobra2) but does on all my USBizi’s, Panda, Panda2, Domino

26

Here’s a weird follow up to this post. I needed more power for an LCD so I connected an external power supply to the Domino I was using, and lo-and-behold, the app kept running when I stopped the debugging session.

There must be something in the way the USB driver disconnects from the debugger that lowers the power capability and appears to hang the app.

@ GHI, any thoughts?

27

On my laptop I’ve installed NETMF and Gadgeteer Package 2013 R3 and the WinUSB driver.

With Windows running, powering the Panda2 via the laptop USB = deployed application does not run.

My laptop has a feature where the USB ports can still supply power even when the laptop is asleep, allowing peripherals to be charged/powered when the laptop is not running.

So, with Windows in sleep mode, powering the Panda2 via the laptop USB = deployed application runs.

This confirms that there is some R3/WinUSB software issue on the PC side that is inhibiting the Panda2 from running.

Also, my Panda2 application normally runs with USBClient disabled. USBClient can be enabled via a toggle switch, allowing my application to expose the Panda2’s microSD card as a memory stick. Enabling USBClient also changes the Panda2’s debugging interface from USB to serial.

With USBClient enabled on the Panda2 and Windows running on the laptop, powering the Panda2 via the laptop USB = deployed application runs.

On a separate machine (a desktop) which has no NETMF or GHI drivers, the Panda2 application always runs when the board is powered by the desktop USB.

@ GHI - Can this issue be added to the Task Tracker? My product relies on the Panda2 being able to run when powered via USB, regardless of what drivers are installed on the machine. The new SDK seems to have broken some previously reliable functionality.

UPDATE: I’ve added this issue to the Task Tracker. If you are affected by this, you may vote here: https://www.ghielectronics.com/tracker/entry/31