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'm extremely new to netduino development. So far I've played around with the piezo (successfully) and the shield base (not so successfully).
I updated the firmware on my netduino go to 4.2.2 and flashed the shield base up to beta 6. I had been able to wire my shield base up and see it do things successfully, but after 1 rebuild I started getting this error:
When I first started working with it I got that message relentlessly (hence why I updated my firmware). I've started a new project with the literally barest of code and its still failing with that message, making me think its something wrong with the hardware.
I'm so new to this, I have no idea how to troubleshoot.
Here's my code, if it helps:
public class Program
public static void Main()
var shieldbase = new NetduinoGo.ShieldBase(GoSockets.Socket5);
It fails on the constructor. I do have it plugged into Socket 5 (I did double check! ) Any help would be greatly appreciated.
Somehow your post got hidden from moderators to approve...sorry that we're just seeing this!
Can you try the following?
1. Update your Shield Base to the latest beta firmware (beta 7)
2. Unplug all modules except for Shield Base. Plug Shield Base into one of the ports 1-4.
3. Create a new "Netduino 2 Application" and try blinking the Pins.ONBOARD_LED. This should map to the Shield Base's socket automatically. If this works, then you're set up...and we can diagnose from there.
Welcome to the Netduino community,
I am like MarcusTheBold very new to the platform. I have the same issue with initializing the shield base. However, blinking the led once before initializing the shield base does solve the problem. After that I can init the shield base without exceptions.
Please let me know how I can help in diagnosing the issue further.
Hmm, very interesting. If you use one of the first four GoPorts instead, does that change things?
Using a short timeout (Thread.Sleep(1000)) may provide a temporary workaround for you. For a permanent fix, we're working on a SPI transport implementation of GoBus (faster, using a single port) for an upcoming Shield Base beta update.
I flashed my Shieldbase to firmware Beta 7 and the result is a slightly worse situation.
Prior to flashing the firmware I would get a System.Exception when trying to instantiate the Shieldbase object.
Now, with Beta 7 firmware, I get the same exception instantiating any module while the Shieldbase is plugged in. (I haven't tested every permutation, but that seems to be the general situation.)
Is there a release point where we can always go to try new firmware releases without having to bother you?
ALSO, the project that flashes the firmware has some code that is unreachable. (Project: STM32ReflashApp, File: Program.cs, Line: 136 & 138) Maybe line 136 can be moved up above line 119 and line 138 can be removed altogether?
Just to confirm...
Shield Base *beta* requires a dedicated GoBus channel. That means that if you plug it into any of ports 1-4, you can't plug any other modules into those ports. You can still however use ports 5-8. This is a temporary limitation, and should be lifted fairly soon, via a firmware update. [Channel 0 is ports 1-4, channel 1 is ports 5-8.]
Are you plugging in modules on the same half of the board as Shield Base beta?
P.S. The latest firmware is always posted as sticky at the top of the forums (production firmware in Netduino/NetduinoPlus forum, beta firmware in Beta forum). We will also be integrating production firmware, along with the new Netduino Update tool, into future SDK installers.
Thanks for responding, Chris. I DID take note of the limitation, but I did NOT interpret that correctly -- I wrongly interpreted the restriction as [put all modules on either ports 1-4 or 5-8] My bad. I did indeed have the modules in port 1 & 2 + the Shieldbase on port 3.
SO, just to clarify, I CAN use other modules, but they cannot share the same channel with the Shieldbase in firmware version Beta7?
So I'll put Button module on port 1, RGB LED on port 2 and Shieldbase on port 5 ... and that should allow me to instantiate all 3 soft objects.
Result: Um ... I cannot get VC# Express to recognize the device at all. But MFDeploy /Erase recognizes it and reports success. Tried restarting VC# Express, tried switching USB ports, tried disconnecting Shieldbase from Netduino Go ... no luck. Port lights do not stay lit for connected modules. VC# Express executes programs but just skips over code.
In short, this looks bad. But there's probably some simple answer. I'm going to go back to the second of the 2 laptops I successfully configured to manage the Netduino Go this week. More reports later.
Yes, go ahead and put ShieldBase beta on GoPort 5 and then all your other modules on GoPorts 1-4.
To start with, pull off the Shield Base beta module and make sure you can talk to the other modules. Then...pull off the other modules and make sure you can talk to the Shield Base beta module. If that works, then add the other modules back in.
Also...I would try updating your Netduino Go to the latest firmware using the "Netduino Update" tool. That will also clear the current app off your board...giving you a known-good starting point.
Ok Chris -
This is turning into some kind of rat's nest of problems. I looked at this thread that promised to show me how to update my Netduino Go firmware.
I began with the steps to detect my current firmware version. (Some deductions gave me that I should be looking at MFDeploy in GUI mode.) And, TO MY SURPRISE, MFDeploy reports that my Netduino Go firmware is v. 4.2.0.
Ok, so I start the instructions to update the firmware and run into the following further problems:
A. The link in step 3 of the update instructions doesn't point to v3.0.1 as it says, but rather to v3.0.2. Ok, so I'll keep moving foward.
B. Using the STDFU Tester, it doesn't recognize my device. Yes, I followed the directions to enter bootloader mode and I repeated them umpteen times also trying WITHOUT that step. Still my device doesn't show up. I'll just move on to the flashing part.
C. There's nothing that is called ST DfuSe Demonstrator...exe (maybe they just meant DfuSeDemo.exe ... I'll try that. NO LUCK it doesn't recognize my device.
So I'm kinda stuck at this point. Only MFDeploy recognizes my Netduino Go and Visual C# Express.
Neither of the tools for flashing seem to recognize it either i Booloader mode or normal mode.
Any suggestions? (Beside resorting to violent abuse of electronics devices?)
My recommendation is still to use the new "Netduino Update" tool to upgrade your Netduino Go mainboard. It really simplifies the process--and is the recommended way to upgrade Netduino hardware. The ST Tools are powerful but can be complicated to match.
You'll need STDFU tools 3.0.3 to make sure you have the right drivers installed. So uninstall your current ST tools (dfuse, stdfu, etc.) and install the ones from the Netduino Update thread...just to make sure you're started on the right foot.
BTW, here's a direct link to the Netduino Update tool. We'll be making this part of the official Netduino SDK installer sometime in a future SDK release.
When you put your Netduino Go into bootloader mode, it should show up in the program. If it doesn't, check in Device Manager and see what it shows up as there. If it's showing up as "Netduino" under USB devices, then it's not in bootloader mode. Unplug the board, hold down the pushbutton and plug in the board--and it should kick into bootloader mode.
This problem is due to the declaration type of the object. It cannot be static. You can simulate this problem using this:
static NetduinoGo.ShieldBase myShield = new NetduinoGo.ShieldBase(GoSockets.Socket5);
A static declaration does work for at least some other modules, but not the shieldbase.
I believe the context in which your declaring your shieldbase object using "[color=rgb(40,40,40);font-family:helvetica, arial, sans-serif;]var shieldbase = new NetduinoGo.ShieldBase(GoSockets.Socket5);" is creating a static variable. [/color]
[color=rgb(40,40,40);font-family:helvetica, arial, sans-serif;]Use a declaration of the type: [/color]
NetduinoGo.ShieldBase myShield = new NetduinoGo.ShieldBase(GoSockets.Socket5);
Thanks, Chris. Sorry if I've monopolized this thread. I didn't even realize I hadn't followed your suggestion until I saw your last response. My bad.
So I used the Update tool. Then I had to jump thru a bunch of hoops to get to test a few different configurations. Your instructions were great, but the device didn't come back to usable straight away. But I was finally able to test they key question: Can I instantiate a Shieldbase object without an exception? No, I cannot.
Here's the line of code I'm trying to power thru:
static NetduinoGo.ShieldBase sBase = new NetduinoGo.ShieldBase((GoBus.GoSocket)5);
Here are the results:
Case 0: Shieldbase on Port 5, no other modules. Result: System.Exception
Case 1: Button on Port 1, RGB LED on Port 2, Shieldbase on Port 5. Result: System.Exception.
Case 2: Button on 1, RGB on 2, no other modules. Result: No errors. Able to instantiate other devices.
So what is next for me here ... I guess I should set up source code for SDK and/or firmware and try to step thru? I guess I'll do the SDK first and see what I find. Does that sound right?
Ah, static. Follow Chris Wilson's suggestion and move the object instantiation (the "new" part after the equals sign) to your main code instead. NETMF may be trying to create the object via GoBus before GoBus is actually initialized.
Statics can be tricky that way, particularly in NETMF.
Did you get your Netduino Go updated to the latest firmware successfully using the new Netduino Update tool?
So apparently the use of the static keyword or trying to declare and instantiate in the same line was the problem.
I now have it working and I'm reading analog input from Channel 0.
(Interesting observations -- the only input "sensor" I had handy was a resistor of some unknown Ohms R. Reading from the open pin (no connection) yielded some raw number like 685 ... but it fluctuated quite a bit. With the resister between A0 and Gnd, It read a very consistent raw datum of 275 +/- 5. And I was able to push it down to nearly 0 when I shorted it with my dry fingers. I'm very surpised that the empty pin produced a more variable result than the R or my dry fingers. Seems strange.)
Now I can commit to buying the XBee Wifi solution.
BTW, where do I send my resume to become more involved in the Netduino project? Are you accepting new people onboard? Perhaps there are subgroups working on new modules?
Awesome, glad that you're up and running now.
Regarding becoming more involved... Where are you located?
We've been working all year on a series of new accessories, firmware features and tools. The first of these to be released were Netduino Update and Visual Studio 2013 support. Lots more to come; I'm looking forward to hearing your experiences with all the new software and gear!
I also have a problem with Shieldbase, I tried to update the firmware (I posted separately), below I am attaching what appears to me on the screen so you can give me some information on how I should do to solve this problem that is blocking any chance 'to go forward in the tests.