The Netduino forums have been replaced by new forums at community.wildernesslabs.co.
This site has been preserved for archival purposes only
and the ability to make new accounts or posts has been turned off.
I think I may have come across a bug when using the ShieldBase in a project.
Start a new VS project using the new 4.2.2 SDK on a Go! and ShieldBase running the latest versions of NETMF and ShieldBase update 5. Connect the ShieldBase to socket 5. Now I am using the Komodex module (I'm sure Chris has one ) to show that there is some activity. My application looks like this:
using System.Threading;
using Komodex.NETMF;
using NetduinoGo;namespace ShieldbaseBug
{
public class Program
{
public static void Main()
{
ShieldBase sb = new ShieldBase((GoBus.GoSocket) 5);
SevenSegmentDisplay display = new SevenSegmentDisplay();
while (true)
{
for (int counter = 0; counter < 9999; counter++)
{
display.SetValue(counter);
Thread.Sleep(200);
}
}
}
}
}
Deploy the application to the Go! and you should see the module start counting. Now stop the debugger and the app should keep on counting. Unplug the Go! and then plug it back in to the PC. Wait a while and nothing happens. The app does not start running.
Now comment out the declaration of sb and repeat. The app starts counting in both cases.
I see the same behaviour with mine even when I define the port for the Seven Segment Display module. I have also tested it with the RGBLed module and the same happens with it.
It also takes a bit after the Shield Base enumerates before any other modules enumerates. I wonder if it has to do with the auto-detection code for the Shield Base.
Hi Mark,
That should work. When you plug back in your Netduino Go, does the app start? Does it get stuck on the Shield Base constructor?
If you put a Debug.Print statement in the code right before the Shield Base constructor--and then unplug/re-attach the board while you're connected in MFDeploy--you can press PING to see the boot up sequence after plugging it back in.
Chris
That should work. When you plug back in your Netduino Go, does the app start? Does it get stuck on the Shield Base constructor?
If you put a Debug.Print statement in the code right before the Shield Base constructor--and then unplug/re-attach the board while you're connected in MFDeploy--you can press PING to see the boot up sequence after plugging it back in.
I think I have followed your instructions correctly I get a message from MFDeploy that there is an uncaught exception.
BTW, the blue light on the ShieldBase socket is turned on.
Also, if you swap the construction order so the SevenSegmentDisplay is constructed first and the ShieldBase second then the app runs fine on power on.
Mark, I got the same in my MFDeploy window. At first I thought I was doing incorrectly. But the Uncaught Exception would only show if I Connected (F5) to the Netduino Go as it was booting up.
I think I have followed your instructions correctly I get a message from MFDeploy that there is an uncaught exception.
If you use the pre-beta "auto-detect" feature on Shield Base, and the shield base is on GoPort 5/6/7/8, you'll get a first-chance exception while the Shield Base is being located.
If you're getting an uncaught exception, or not using auto-detect with the Shield Base, I would really appreciate a short repro and info so we can investigate further.
Thank you,
Chris
If by "auto detect" you mean not specifying the port in the ShieldBase constructor then I'm not doing that. I'm using the code in the first post in this thread.
In order to reproduce the uncaught exception I did the following:
Create a new Go! project using the code in the first post. Add a Debug.Print before the ShieldBase constructor as you requested. Deploy the application using VS. The application will start running.
Disconnect VS by stopping the debugging. The application continues to run.
Start MFDeploy and ping the board. I get a TinyCLR response in MFDeploy.
Unplug the board wait a second or two and plug it back into the PC.
When the board shows up in MFDeploy hit Ping. This generates the exception message.
Let me know if you need more information or if I have misunderstood your request from last night regarding steps to generate additional information.
I think I may have come across a bug when using the ShieldBase in a project.
Start a new VS project using the new 4.2.2 SDK on a Go! and ShieldBase running the latest versions of NETMF and ShieldBase update 5. Connect the ShieldBase to socket 5. Now I am using the Komodex module (I'm sure Chris has one ) to show that there is some activity. My application looks like this:
using System.Threading;using Komodex.NETMF;using NetduinoGo;namespace ShieldbaseBug{ public class Program { public static void Main() { ShieldBase sb = new ShieldBase((GoBus.GoSocket) 5); SevenSegmentDisplay display = new SevenSegmentDisplay(); while (true) { for (int counter = 0; counter < 9999; counter++) { display.SetValue(counter); Thread.Sleep(200); } } } }}
Deploy the application to the Go! and you should see the module start counting. Now stop the debugger and the app should keep on counting. Unplug the Go! and then plug it back in to the PC. Wait a while and nothing happens. The app does not start running.
Now comment out the declaration of sb and repeat. The app starts counting in both cases.
Bug or am I missing something?
Regards,
Mark
I had same problem when unplug the NGo! and then plug it back in to the NGO.
This may be an initialization timing issue. I encountered this problem even after updating GO/SB firmware. Adding a one second delay as the very first line of code resolved it for me.
public static void Main() { System.Threading.Thread.Sleep(1000); NetduinoGo.ShieldBase sb = new NetduinoGo.ShieldBase(GoSockets.Socket2);
Hmm, interesting.
It sounds like the Shield Base is having troubles transitioning between enumeration and GoBus communication in this circumstance.
We haven't been able to reproduce this here, but I'll see what we can do to eliminate the delay workaround. We should definitely be able to fix this in a firmware update.
At first glance it sounds like the board is still booting during enumeration and we might be rebooting it before it gets a chance to start.
eplaksienko--I might take you up regarding taking a look on your hardware.
Chris