I’ve got a Panda II board that seems to have an issue as soon as I even declare a PWM port. Runs fine until I add the PWM line to the otherwise default code:
using System;
using System.Threading;
using Microsoft.SPOT;
using Microsoft.SPOT.Hardware;
using GHIElectronics.NETMF.FEZ;
using GHIElectronics.NETMF.Hardware; //new
namespace FEZ_Panda_II_Application1
{
public class Program
{
public static void Main()
{
// Blink board LED
bool ledState = false;
OutputPort led = new OutputPort((Cpu.Pin)FEZ_Pin.Digital.LED, ledState);
PWM fud = new PWM((PWM.Pin)FEZ_Pin.PWM.Di10); //new
while (true)
{
// Sleep for 500 milliseconds
Thread.Sleep(500);
// toggle LED state
ledState = !ledState;
led.Write(ledState);
}
}
}
}
Code says it is updating, but simply exits the debugger, no errors or messages. FW is 4.1.8.0 on the device. Am I missing an update? Does PWM not work on the Panda II? Thanks.
I have a Panda (not a Panda2) in front of me - 4.1.8.0 is the “current”/last firmware so you’re up to date there.
I have exactly the same code and it works fine. Have you tried with a different pin for example, to see if that is the issue? Can you check that you do have the two GHIelectronics.NTEMF.Hardware references added - the USBizi specific one in particular?
I haven’t connected to see if I get a PWM pulse, but I can step thru this code no problem.
PWM fud = new PWM((PWM.Pin)FEZ_Pin.PWM.Di10);
fud.SetPulse(1000, 500);
can you step debug in your code without the PWM and see the LED blink ? It could possibly be related to the USB driver stack - there are some peculiarities with modern drivers (from the 2013+ GHI SDKs). What is the history of your PC and SDK installs, and do you use the winusb drivers or the legacy drivers ?
Yes, I’ve tried all the pins, and they all have the same effect.
I did not have the GHIElectronics.NETMF.Hardware.USBizi reference; but adding it did not seem to fix the problem.
When I attempt to step into the code, it then tells me that “GHIElectronics.NETMF.FEZ” is not recognized, and am I missing a reference; why it didn’t mention until I tried to single-step is curious. I tried adding FEZPanda_II_GHIElectronics.NETMF.FEZ, and this eliminates the error, but does not solve the problem (still kicks it out of the debugger attempting to step into the code).
Yes, if I comment-out the PWM line, all behaves as normal: debugger runs, blinks the LED and stays in the debugger until I stop it.
It almost behaves as if configuring the pin is interfering with the download mechanism itself.
You might be on to something with the drivers. I’m also doing a project with a FEZ Hydra, and it’s possible I’ve stepped on something there. I didn’t suspect it before because it’s been behaving pretty close to normal up until the PWM thing.
How do I tell if I have winusb or legacy? I’m running Win7 pro 32-bit.
I don’t have a Fez with me now, but if you connect it you can see the device driver in Device Manager, and I’m pretty sure it explicitly lists “WinUSB” in one of the tabs in the device properties/info.
I would also, to be ultra sure, step thru the manual firmware process again to make sure there’s no issue with this (because this “instant crash” behaviour is more like what I’d expect with a firmware/sdk mismatch than just a driver issue)
Just FYI, and this is not going to affect this problem scenario for you, there is a known situation where an app appears to stop on a USBizi based device if you halt debugging in VS (at least in VS2012). If for example in your LED blinking app you have a breakpoint before the while loop, you start debugging, breakpoint is hit, you step thru a few cycles of the LED flashing, then hit F5 and the LED flashes… then you stop debugging, and the LED stops too. Not what is usually expected. At that point you can open MFDeploy and connect to the device and the app will continue to run. As I said, not a problem that you’ve clearly hit, but another thing to think about.
Just tried the same thing on my Panda II at work - bought and installed earlier - and it’s working. FW is 4.1.6.0. Curious the device manager doesn’t show a device at all under USB controllers.
I think I’ve got enough to start swapping things out to see what’s causing the issue. I’ll start by downgrading the FW and might try re-installing MSVC and drivers on a VM.
Sounds like firmware/SDK mismatch. The “latest” is 4.1.8.0 as Brett mentioned earlier. I would update the firmware to make sure it matches the installed SDK.
Ack - board lost my post, so I’ll type it in more briefly:
Old SDK was 4.1.6.0, so updated to 4.1.8.0 to match my current FW. While release runs, including when I add a declare for the PWM pin, the debugger loops several times resetting the USB connection, then dumps me out of the debugger. Suspect I might have a USB driver left over from the Hyrdra install that might be causing problems? If I have to I might do a fresh install in a VM just to make sure.
The firmware 4.1.8.0 / SDK 4.1.6.0 mis-match caused the thing to fail to download or debug; so not only is it important to make sure your FW is not [em]older [/em]than the SDK, it’s also important that they [em]match[/em].
After fixing this, I had an issue with not being able to run the debugger. This was fixed by removing, and deleting, the (I think) GHI custom debugger USB driver, then letting it install the Windows (7) default one.
All better now. Thanks guys! (although I’ll probably be back when I go back to my Hydra board
Oh yes, that’s a guaranteed problem - they always must match ! If you saw anywhere posted that being older was the only problem, let us know so we can have that amended - absolutely they have to match.
here’s to hoping you’re around but for all the right reasons - the Hydra shouldn’t be an issue for you with the modern drivers
