Main Site Documentation

Problems with Mountaineer USB right out of the box


#1

I just received a new Mountaineer USB board and am trying to get it up and running. I followed the instructions in the “Getting started with Mountaineer” document off the Mountaineer website. The steps are pretty straight forward so I think I got them right: 1) Install MS Visual Studio 2010 C# , 2) Install .NET Micro Framework SDK. The link in the Getting Started document loads .NET MF 4.2 RTM (QFE1) which is what I think the Mountaineer board is expecting. 3) Install the .NET Gadgeteer Core and the Mountaineer SDK. 4) Install the Mountaineer USB drivers.

I did all that and built the LED blink program in the Getting Started document. It built fine but when I try to start debugging, I get the following:

------ Deploy started: Project: MntrApp2, Configuration: Debug Any CPU ------
------ Deploy started: Project: MntrApp2, Configuration: Debug Any CPU ------
Device not found or cannot be opened - USB:Gadgeteer========== Deploy: 0 succeeded, 1 failed, 0 skipped ==========

I tried all this originally on a Windows 7 64 bit OS machine and then did the exact same thing on a Windows 7 32 bit OS machine with the exact same results. Seems like I have a very basic mistake somewhere but I sure can’t find it. If I can get this hardware working then there is a good probability it will solve some very big problems I’m having on a project at work so any help will be greatly appreciated.

Thanks - Gene


#2

The first thing to check is what do you see under device manager?


#3

Wow, many thanks for the quick response.

It looked just like the Getting Started doc. Originally, the “Mountaineer USB” showed up under other. Then I “Updated the driver software” like the GS doc said. Now the “Mountaineer USB” shows up under "Universal Serial Bus controllers in Device Manager. However, I don’t hear the usual chime when I unplug/plug the Mountaineer in and out of the USB hub nor do I see theusual window show up in the lower right corner of my display saying the Mountaineer device is ready for use.

Another piece of information that may be important. After reading a little more on this Wiki, I tried running a Micro Framework console application (not a Gadgeteer template) that does nothing but Debug.Print and that worked fine.


#4

One more piece of information. I downloaded and ran MFDeploy. I can see the Mountaineer USB_a7e70ea2 as a “USB” device. When I hit the “Ping” button, the window shows “Pinging … TinyCLR” and nothing else. Not sure whether than means it pinged successfully or not.

Thanks for the help


#5

Gus

If you’re still there, I have another option to run by you. I bought a GHI Spider at the same time I bought the Mountaineer board. The Mountaineer is better suited for my final application but if I can make progress with the Spider, I’m happy to give that a try. I haven’t started down this road yet since there seems to be some issue with the Mountaineer wanting NETMF 4.2 QE1 and the Spider wanting QE2. If you think I can make progress with the Spider writing a simple application that just reads and writes 3 RS232 serial ports, can I uninstall everything but Visual Studio 2010 and reinstall NETMF 4.2 QE2 and the GHI Software package V4.2? Will I still be able to use the Mountaineer board?

Thanks - Gene


#6

@ Gene - We are always here but on a Sunday, not all day :slight_smile:

Both boards should work for you but we need ot concentrate on one of them to help you get it going.


#7

@ Gene, welcome to the forum!

When you use MFDeploy and try PINGing the device, a response of TinyCLR means that the framework is running and that it’s responding.

Can I ask you to open MFDeploy and check the framework version that it has deployed on it? Target --> Device Capabilities. It needs to match the QFE1 version that the Mountaineer board SDK has in it. Those two have to match to be reliable

One thing about connecting and disconnecting the device. The first time you use a port, the device should tell you it’s ready to use, but subsequent connections won’t. But each time you disconnect or reconnect the device, you should hear the USB Device Connect/disconnect sound come up and it should reliably appear in device manager. If you have DevMgr open and in front, and connect the device you should see it auto-scan for new device and show up; then disconnect and auto scan should show it removed.


#8

Thanks for the responses. I’ve been bashing my head against the keyboard for a while now and here is where I’m at.

  1. I am concentrating on the Spider board since I was able to make some progress with that.
  2. I wasn’t able to get the Gadgeteer part of that going so I’ve been concentrating on a simple Micro Framework Console Application for reading and writing to a serial port. I’ll work on the Gadgetter part later unless someone tells me it will be easier to get serial ports running with the Gadgeteer stuff
  3. I’m trying to talk to a DGH data acquisition module which are somewhat fussy devices.

I can talk to the DGH with Terraterm at 38400, no parity, one stop bit 7 data bits and get correct responses.
I can talk to and read from Terraterm from my code running on the Spider with the same port settings
I can’t talk to the DGH from the Spider. I can see the data going out from the Spider on an Oscope but I just don’t get any response back from the DGH Here’s my code:

using System;
using Microsoft.SPOT;
using System.Threading;
using System.IO.Ports;
using System.Text;

namespace MFConsoleApplication1
{
    public class Program
    {
        public static void Main()
        {
            Debug.Print("\r\nStarting Program ... \r\n");

            SerialPort UART = new SerialPort("COM2", 38400, Parity.None, 7, StopBits.One);
            int read_count = 0;
            byte[] tx_data;
            byte[] rx_data = new byte[11];

            //$1RD terminated with CR is the command to read data from the DGH.
            string readCommand = "$1RD\r";
            tx_data = Encoding.UTF8.GetBytes(readCommand);
            
            UART.ReadTimeout = 10;
            UART.Open();
            // flush all data
            UART.Flush(); 
            
            while (true)
            {
                // send some data
                UART.Write(tx_data, 0, tx_data.Length);
                // wait to make sure data is transmitted
                Thread.Sleep(100);
                // read the data, should be 10 bytes terminated with a CR
                read_count = UART.Read(rx_data, 0, 10);
                Debug.Print(rx_data.ToString());
                Thread.Sleep(1000);
            }    
        }

    }
}

The Debug.Print(rx_data.ToString() gives “System.Byte[]” in the Debug Output window so I’ve been using the debugger with a breakpoint at the UART.Write line.

Any help will be greatly appreciated.

Cheers - Gene


#9

Using code tags will make your post more readable. This can be done in two ways:[ol]
Click the “101010” icon and paste your code between the

 tags or...
Select the code within your post and click the "101010" icon.[/ol]
(Generated by QuickReply)

#10

Will do


#11

Your pattern is not very resistant to delayed data. You also don’t ever look how many bytes are received and that might tell you more about what is going on.

Here’s some code I had in a test UART app

               read_count = UART.Read(rx_byte, 0, 1);
                if (read_count > 0)// do we have data?
                {
                    // create a string
                    string counter_string =
                            "You typed: " + rx_byte[0].ToString() + "\r\n";
                    // convert the string to bytes
                    byte[] buffer = Encoding.UTF8.GetBytes(counter_string);
                    // send the bytes on the serial port
                    UART.Write(buffer, 0, buffer.Length);
                    Debug.Print("Got character " + (char)rx_byte[0]);
               }
 

And just wrap that in a While(true) loop and you should see what you get in - and when you get your terminator character, break the loop (or do it properly without break :slight_smile: )


#12

OK, after a fairly brutal day and a half, I’ve got a reasonable start on my .NET MF serial port application. In hindsight it wasn’t actually all that bad since I went from first hearing about .NET MF, Gadgeteer and GHI electronics Wednesday night, ordering hardware on Thursday, getting it in Friday afternoon and having the first part of my app running on Saturday evening. Thanks for all the help from this forum. Now that I know a little bit about what is going on, I have a bunch more general questions but I’ll start those in another thread.

Thanks again for all the help - Gene