I’m new to programming with .NETMF etc, so apologies if I’ve missed something really obvious.
What I’m trying to do is to get get the USB Client - Mass Storage code example (GHI Electronics – Where Hardware Meets Software) to work on a FEZ Panda II board. The code seems to compile without any error or warnings, and I have a 16Gb SDHC card permanently inserted into the reader, with a test file that I’d written with some earlier test code on the SDHC card (I’m no longer writing any new data to the card).
My expectation, having compiled and downloaded the code was that the SD card (and it’s contents) would appear as a USB removable storage device in “My Computer” on windows - and hence I’d be able to access the SD card here. However, the SD card does not appear in “My Computer”. So far as I can tell, Windows sees the FEZ Panda II as a “GHI .NET Micro Framework USB Debugging Interface” according to the device manager.
Any ideas what I’ve done wrong and how I can fix it?
I think it should be USB debugging since I previously ran the “USB debugging with virtual COM channel” example - which requires the download of a new driver which I believe I’m now using.
Ok, having searched again through some of the forums, it seems some of the posts mention a mode pin, of which further details are given in the “book & wiki” - which book may I ask? It’s not mentioned in the “Beginners guide to NETMF.pdf” (I searched) - is there another book that I’ve missed?
I’ve tried connecting the mode pin (previously open circuit) to ground, then re-powering the device and trying to ping it with MFDeploy. I get no response from COM1, COM3, or USB. Removing the jumper and re-powering the device I do get a response from USB.
Should this jumper have an effect on the MSC / getting the SD card recognised by windows?
welcome first up - this is your only thread so far, hope you’re having fun (besides the mode pin confusion!)
Disclaimer: I have not played with Mass storage at all, so I’m not saying things from experience, just from exposure to this info through the forum and reading the docs.
First reference is the USB Client info Mike pointed to. From there, I took away two things. First is:
So if you don’t have MODE tied to GND, the code should throw an error when you hit F5 to deploy the code to the device - it should report the error in the code:
throw new InvalidOperationException("Current debug interface is USB. It must be changed to something else before proceeding. Refer to your platform user manual to change the debug interface.");
So now, disconnect Fez, connect your MODE pin to ground, connect to your PC again.
Then when you hit F5, your deployment should fail because it’s no longer working on USB debug.
Then, if you unplug the device and reconnect, it should show up as a mass storage device. If not, then the second takeaway comes into play:
So now make sure COM1 Rx is tied high.
Then, reconnect your device and you should be golden !
So since I was “inquisitive”, I tried this myself. When I connected my Panda II with MODE tied to GND (with a pull-down resistor) the device booted first time. Second time it didn’t. Third time it didn’t. Fourth it did. So it’s certainly the Rx float that’s a problem. I tied it to 3v3 with a pull-up resistor, and it hasn’t failed.
I also debugged it using the classic microcontroller debug interface (because I wasn’t connecting a debugger any other way) so I put an LED on a digital pin, thru a resistor, to GND and then toggled it at different speeds at different parts of the code, for example:
var i = 20;
while (i != 0)
{
Thread.Sleep(250);
// toggle LED state
ledState = !ledState;
led.Write(ledState);
i--;
}
that way, I knew that if it flashed at ~4/sec the code was at this point; if it hit the exception (that I wouldn’t be able to see without USB debugging working properly) the flashing was at only a 50msec sleep so it flashed very quickly. Another good tip for you.
Brett - thanks for your reply. I must be doing something wrong, could it be this:
I notice the image at the top of the USB Client wiki page shows an extra board (with 9 pin D connector - RS232?) piggy-backed on top of a FEZ board. I assume I’m meant to use this 9 pin D to deploy (download) the code to the FEZ board and receive back any debug messages, whilst the USB connector on the Panda II lets windows access the SD card?
It seems I don’t have this RS232 board in the kit that accompanied the Panda II (though it is possible a colleague who is away this week has “borrowed” it! - I’ll have to wait to next week to find out). Is it not possible to deploy the code in the USB Client / Mass Storage example to the Panda II via USB, disable any debug messages if these these would conflict with the MSC using USB, then when rebooting the device I should be able to access the SD card from Windows? This would assume that the code works and therefore doesn’t need to print any debug messages…
let me just reiterate, I didn’t use the RS232 board when I did my tests. I don’t have one, so couldn’t even if I wanted to.
That board is a RS232 shield, and would allow you to do debugging over the serial port, but here’s how to get around that. Just use a resistor or a wire that bridges the MODE pin and GND that are next to each other on the external connector… you remove it and reset your device, deploy your new code from Visual Studio, then replace the resistor and reset your device.
Add the LED blink code above and wire in a LED (you can’t use the onboard LED as it’s connected to the MODE pin - make sure the flash speed is set at different rates so you know where the code is up to. Work your way through the steps above and let us know how you go.
Edit: add in your location on the forum profile so people know where you’re at so maybe someone local can throw out options if you don’t have stuff like LEDs.