Netduino home hardware projects downloads community

Jump to content


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.
Photo

Shield Base Firmware v4.2.0.1 (beta 1)


  • Please log in to reply
36 replies to this topic

#1 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7767 posts
  • LocationNew York, NY

Posted 18 June 2012 - 02:08 PM

Version: 4.2.0.1 beta 1 Based on community bug reports and repros, we have been able to isolate and fix a few PWM bugs which affected the Shield Base. Details on that bug can be found in the second post of this thread (along with the bugfix which we've submitted to Microsoft). This firmware includes the following updates: 1. PWM no longer stops working 'randomly' 2. PWM scale now works properly This firmware is part of a bigger update to the Shield Base firmware. The next update will be to move go!bus communication over to the error-corrected SPI channel. NOTE: if you are using your Shield Base (with upgraded STM32F2 chip) as a standalone NETMF board, you'll want to continue using the production 4.2.0.0 NETMF firmware. We will make a standalone firmware release available when 4.2.0.1 leaves beta. To upgrade your Shield Base, plug it into socket 5 on your Netduino Go. Deploy the attached app, and watch your Output window. Socket 5's LED will flash during the process, and the Output window will show you details. When the Shield Base is completely updated, the white power LED will flash. After the upgrade, simply erase the update app or deploy a new app to your Netduino Go mainboard. If you have trouble communicating with the shield base, cycle power on your Netduino Go. Please post in this thread if you have any troubles, and let us know how the updated PWM functionality works for you. Thank you for beta testing the Shield Base, Chris P.S. We've discovered a quirk in the NETMF STM32 flash drivers which seems to intermittently affect deployment of really large apps like this one. If you run into troubles deploying this app (or another app immediately after this one), you can erase and reflash your mainboard. We're looking into it, and hope to contribute back any bugfixes to the NETMF core.

Attached Files



#2 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7767 posts
  • LocationNew York, NY

Posted 18 June 2012 - 02:08 PM

For those wondering what the PWM bug was, it was an issue that affects all .NET MF 4.2 hardware.

Basically, the Dispose routine for the PWM class would stop the timer driving the PWM channel. That's a good thing. Unfortunately, the same Dispose routine was also called by the finalizer.

Here's the scenario:
  • User creates PWM object in code
  • User disposes of PWM object
  • User recreates PWM object, using the same channel as before
  • At some unknown point in the future, the garbage collector calls the finalizer on the old PWM object
  • The old PWM object's finalizer "re-disposes" of the PWM channel's timer; this shuts down the timer on the _new_ PWM object, since the hardware timer is tied to a PWM channel.
This has been fixed by adding a _disposed instance-level variable which makes sure that the object is not accidentally disposed of a second time.

To make things more interesting there was a second bug. Basically the constructor for PWM, if it encountered an exception (like a user creating a PWM channel on a pin which was in use) then it would dispose of the PWM resources. But it wouldn't return an error. So if a user created a new PWM instance using a channel which was already in use...the new PWM would appear to be instantiated...but the old PWM object would stop working and the new one wouldn't work either.

We have patched this second bug by re-throwing any exceptions in the PWM class constructor. Further work should be done to check the pin reservation before doing the PWM init, but this first step will raise a red flag for most design-time issues.

I have attached the updated PWM.cs class, for those interested. You do not need to download it to take advantage of the bugfixes in the firmware.

C:\MicroFrameworkPK_v4_2\Framework\Core\Native_Hardware\Native_PWM\PWM.cs

Chris

Attached Files

  • Attached File  PWM.cs   10.68KB   63 downloads


#3 Gutworks

Gutworks

    Advanced Member

  • Members
  • PipPipPip
  • 363 posts
  • LocationOttawa, Ontario

Posted 18 June 2012 - 05:46 PM

Awesome news! I'm trying to get an earlier flight home so I can try it this evening. Thank you! Steve

#4 carb

carb

    Advanced Member

  • Members
  • PipPipPip
  • 352 posts
  • LocationCrystal River, Florida

Posted 18 June 2012 - 08:39 PM

Chris,

I am having a few problems with the shield base firmware.

I loaded the new firmware, no problem (blue flashing led, white flashing led etc.)

Loaded a small test VB test program that I have run before.

Got the output window info:

Create TS.

Loading start at 8056cd0, end 806dbf8

Assembly: mscorlib (4.2.0.0)

Assembly: Microsoft.SPOT.Native (4.2.0.0)

Assembly: Microsoft.SPOT.Hardware (4.2.0.0)

Assembly: Microsoft.SPOT.Hardware.SerialPort (4.2.0.0)

Assembly: Microsoft.SPOT.IO (4.2.0.0)

Assembly: System.IO (4.2.0.0)

Assembly: Microsoft.SPOT.Hardware.PWM (4.2.0.1)

Assembly: Microsoft.SPOT.Hardware.Usb (4.2.0.0)

Assembly: SecretLabs.NETMF.Diagnostics (4.2.0.0)

Assembly: SecretLabs.NETMF.IO (4.2.0.0)

Loading Deployment Assemblies.

Attaching deployed file.

Assembly: NetduinoGo.RgbLed (1.0.0.0)

Resolving.

Link failure: some assembly references cannot be resolved!!


Assembly: NetduinoGo.RgbLed (1.0.0.0) needs assembly 'GoBus' (1.0.0.0)

Error: a3000000


Waiting for debug commands...


I made sure that I had a reference to gobus.

Tried again, same error.

Rebuilt the Solution.

Deployed program fine.

If I change any of the code such as changing from "TempSensor.Read.ToString("n3")" to "TempSensor.Read.ToString("n1")" I get the same error, have to rebuild, cycle power to the Netduino Go, and then it will deploy.

My code is:
Imports Microsoft.SPOT
Imports Microsoft.SPOT.Hardware
Imports SecretLabs.NETMF.Hardware
Imports SecretLabs.NETMF.Hardware.NetduinoGo
Imports NetduinoGo

Module Module1
  Dim SB As ShieldBase
  Dim Relay1 As Microsoft.SPOT.Hardware.OutputPort
  Dim TempSensor As AnalogInput
  Dim RelayOn As Boolean = False
  Dim A0In As Boolean = False
  Dim Led As RgbLed

    Sub Main()
    SB = New ShieldBase(GoSockets.Socket2)
    Led = New RgbLed(GoSockets.Socket7)

    TempSensor = New AnalogInput(SB.AnalogChannels.ANALOG_0)
    Relay1 = New OutputPort(SB.Pins.GPIO_PIN_D4, False)

    Relay1.Write(True)
    While True
      RelayOn = Relay1.Read
      Thread.Sleep(2500)
      A0In = TempSensor.Read > 0.5
      Debug.Print("The D0 port is " + RelayOn.ToString + (If(A0In, "    ", "   ")) + "The A0 port = " + TempSensor.Read.ToString("n3"))
      'Debug.Print("The A0 port = " + TempSensor.Read.ToString("n4"))
      If A0In Then
        Led.SetColor(0, 255, 0)
      Else
        Led.SetColor(255, 0, 0)
      End If
      Relay1.Write(Not RelayOn)
    End While
  End Sub
End Module

Any ideas?
Chuck

#5 Jack Chidley

Jack Chidley

    Advanced Member

  • Members
  • PipPipPip
  • 99 posts

Posted 18 June 2012 - 10:06 PM

Chris,

I am having a few problems with the shield base firmware.

I loaded the new firmware, no problem (blue flashing led, white flashing led etc.)

Loaded a small test VB test program that I have run before.

Got the output window info:


I made sure that I had a reference to gobus.

Tried again, same error.

Rebuilt the Solution.

Deployed program fine.

If I change any of the code such as changing from "TempSensor.Read.ToString("n3")" to "TempSensor.Read.ToString("n1")" I get the same error, have to rebuild, cycle power to the Netduino Go, and then it will deploy.

[...]

Any ideas?
Chuck


I had a similar issue. Your work around works for me too. Can't get the shield base to light up an LED either.

#6 carb

carb

    Advanced Member

  • Members
  • PipPipPip
  • 352 posts
  • LocationCrystal River, Florida

Posted 18 June 2012 - 10:59 PM

Can't get the shield base to light up an LED either.

Jack,
Which LED are you refering to? My blue socket led is working. There is no LED on the shield base itself.
Chuck

#7 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7767 posts
  • LocationNew York, NY

Posted 19 June 2012 - 01:10 AM

Hi Chuck, Jack: Do you have a repro I can test here (solution in ZIP file)? Sounds like a Visual Studio bug; I would love to hunt it :) Jack -- could you please post the code sample that's not working for you? Chris

#8 Jack Chidley

Jack Chidley

    Advanced Member

  • Members
  • PipPipPip
  • 99 posts

Posted 21 June 2012 - 05:40 PM

Chris, here's my program:

using System;
using System.Threading;
using Microsoft.SPOT;
using Microsoft.SPOT.Hardware;
using SecretLabs.NETMF.Hardware.NetduinoGo;

namespace NetduinoGoApplication4
{
    public class Program
    {
        public static void Main()
        {
            // write your code here
            NetduinoGo.ShieldBase shieldBase = new NetduinoGo.ShieldBase(GoSockets.Socket5);

            Microsoft.SPOT.Hardware.OutputPort ledPort = new Microsoft.SPOT.Hardware.OutputPort(shieldBase.Pins.GPIO_PIN_D13, false);

            while (true)
            {
                ledPort.Write(!ledPort.Read());
                System.Threading.Thread.Sleep(500);
            }
        }
    }
}

There's a single LED pugged directly into D13/GND.

Sometimes this works, sometimes I get

Assembly: NetduinoGo.ShieldBase (0.1.0.0) needs assembly 'GoBus' (1.0.0.0)

Error: a3000000

Waiting for debug commands...

The program '[4] Micro Framework application: Managed' has exited with code 0 (0x0).

No code changes. Fix seems to be to unplug the GO and then plug it back in.

This happens on both the old version of the Shield Base firmware and the new.

I also have another problem where the sockets on the Netduino Go become completely unresponsive: nothing works, no power, nothing. The program appears to deploy normally and exits with code 0. But no flashing LED.

After many attempts it will work again.

I can't identify a pattern for either of these problems. Sorry. I have tried.

I have tried to swap between 2 programs, one that binks the rgb attached to Socket 4 and another that blinks the LED attached to the shield on socket 5. Even after I "successfully" deploy the swapped program, the binking LEDs don't switch - perhaps a deployment problem?

Attached Files



#9 NXTwoThou

NXTwoThou

    Advanced Member

  • Members
  • PipPipPip
  • 68 posts
  • LocationTulsa, OK

Posted 21 June 2012 - 08:43 PM

If you haven't already, switch to the shortest Go cable you can find, see if it helps any. I was using the 10cm and just by switching to the 5cm it reduced my problems massively(with the original firmware)

#10 Jack Chidley

Jack Chidley

    Advanced Member

  • Members
  • PipPipPip
  • 99 posts

Posted 21 June 2012 - 08:47 PM

I got really excited. Then I realised that I am already using the shortest possible cable. :( Keep the suggestions coming!

#11 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7767 posts
  • LocationNew York, NY

Posted 21 June 2012 - 10:57 PM

Hi Jack,

The error you're getting...

Assembly: NetduinoGo.ShieldBase (0.1.0.0) needs assembly 'GoBus' (1.0.0.0)
Error: a3000000

...generally indicates that there's either an assembly missing in your project or Visual Studio had trouble deploying the app. That's a boot-time message from the Netduino Go that the assembly is missing; it isn't likely to be related to the modules attached to your Netduino Go.

Are you available a bit later to run through this in Netduino Chat? I have a few ideas, and I'd like to run through them with you... My guess is that there's an assembly mismatch somehow or one of the sectors on the mainboard didn't get erased fully (both things that we may be able to address in an SDK/firmware update for the mainboard).

Chris

#12 Jack Chidley

Jack Chidley

    Advanced Member

  • Members
  • PipPipPip
  • 99 posts

Posted 22 June 2012 - 04:02 PM

Actions:

I programmed the Shield Base directly, using the com port. Using the pin assignment given above, all the ports tested OK. The shield base works perfectly every time.

Then I reflashed my Go and to my surprise it worked normally with Go modules, like rgb led). But the Shield Base would still not work when programmed through the Netduino Go. Using my earlier LED blinking program I got this error:
The thread '<No Name>' (0x2) has exited with code 0 (0x0).
A first chance exception of type 'System.Exception' occurred in NetduinoGo.ShieldBase.dll
An unhandled exception of type 'System.Exception' occurred in NetduinoGo.ShieldBase.dll
The thread '<No Name>' (0x1) has exited with code 0 (0x0).
It is this line that cases the problem:
Microsoft.SPOT.Hardware.OutputPort ledPort = new Microsoft.SPOT.Hardware.OutputPort(sb.Pins.GPIO_PIN_D13, false);

I am pretty sure that nothing is deployed to the Shield Base because my existing program, earlier directly deployed to the Shield Base via the COM port (flashing the LED on port A5) runs unchanged.

So, I erased the Shield Base's program using MFDeploy/Com port and reflashed the Shield Base. Then my simple LED Flashing app ran for a few seconds before getting the same exception as before. Oddly the LED was on, in real life!, much longer than off, even though the code is:
            while (true)
            {
                ledPort.Write(!ledPort.Read());
                System.Threading.Thread.Sleep(500);
            }

Finally I unplugged the Go for a while (about an hour) came back and plugged it back in. VS 2010 was not debugging it at the time as I had earlier stopped debugging. The LED blinked normally. I deployed the code back to the device a couple of times. Debugged OK too. Then I changed a line and bingo! Same error as before:
Assembly: NetduinoGo.ShieldBase (0.1.0.0) needs assembly 'GoBus' (1.0.0.0)
Error: a3000000
Jack
PS: I am happy to a have Netduino chat - but I am in the UK so don't make it too late!

#13 Kirk K

Kirk K

    New Member

  • Members
  • Pip
  • 7 posts

Posted 23 June 2012 - 05:44 AM

This is my first go at any *duino boards. I have a background in C# and after watching the webcast, became very interested in the Netduino Go. So I purchased one along with two shieldbases, how my excitement was short lived as the project that I am planning on working on requires multiple servos. To make matters worst, I could not get my sheildbase to properly pulse my servo.

After updating my shield base firmware I am smiling again. So here is my first go:


public class Program
    {
        public static bool IsClosing = false;
         public static void Main()
        {
            Thread[] servoThreads = new Thread[4]; //Create an array to hold servo threads
            // write your code here
            using(ShieldBase sb = new ShieldBase(GoSockets.Socket5)) //Create the ShieldBase instance
            {
                Servo _Servo1 = new Servo(sb.PWMChannels.PWM_0); //Create the servo1 object. This is connected to Digital I/O PIN 5
                Thread t1 = new Thread(new ThreadStart(_Servo1.ActivateServo)); //Create the child thread to run the first servo
                t1.Start(); //Starts the thread
                servoThreads[0] = t1;
                //Do some work
                Thread.Sleep(1000);
                _Servo1.Degree = 180;
                Thread.Sleep(1000);
                _Servo1.Degree = 0.1;
                Thread.Sleep(1000);
                _Servo1.Degree = 90;
                Thread.Sleep(1000);
                IsClosing = true;

                bool isChildThreadAlive = true;
                while(isChildThreadAlive) //Ensure that the child thread(s) have fully exited before closing parent
                {
                    for(int i = 0; i < servoThreads.Length; i++)
                    {
                        if(servoThreads[i] == null)
                            continue;
                        if(servoThreads[i].IsAlive)
                        {
                            isChildThreadAlive = servoThreads[i].IsAlive;
                            break;
                        }
                        isChildThreadAlive = false; //Go ahead and exit no active servo threads found 
                    }
                    Thread.Sleep(500);
                }
            }
        }


    }

    public class Servo
    {
        uint _Duration = 0;
        public double Degree
        {
            set
            {
                _Duration = CalculatePulseFromDegrees(value);
            }
        }
        private Microsoft.SPOT.Hardware.Cpu.PWMChannel _Channel;
        public Servo(Microsoft.SPOT.Hardware.Cpu.PWMChannel pwmChannel)
        {
            _Channel = pwmChannel;
            _Duration = CalculatePulseFromDegrees(90);
        }

        private uint CalculatePulseFromDegrees(double degree)
        {
            uint neutralPulse = 1500; //This represent the neutral pulse time (in microsecond) of the servo typically when the servo is at 90 degrees. ;
            float factor = neutralPulse / 90; //This value represent pulse time when the servo is at 1 degree;
            uint outPulse = (uint)(factor * degree);
            return outPulse;
        }
        public void ActivateServo()
        {
            using(PWM pwm = new PWM(_Channel, 20000, _Duration, PWM.ScaleFactor.Microseconds, false)) //Initializes PWM port
            {
                pwm.Start(); //Start the PWM port
                while(!Program.IsClosing) //Loop until we get a signal to exit
                {
                    pwm.Duration = _Duration; //Sets the duration. This value tells the servo how far to move
                    Thread.Sleep(10); //Sleep for 10ms. 
                }
                pwm.Stop();
            }
           
        }
    }


#14 KJ Lawrence

KJ Lawrence

    New Member

  • Members
  • Pip
  • 1 posts

Posted 29 June 2012 - 10:32 PM

I wanted to follow up on this thread and see if there was any progress made on resolving the issue Jack had? I had a very similar issue with my Netduino Go and Shield Base. If I tried to create a new Output port with digital pins 0 or 1 on the Shield Base I would get a very similar exception. I didn't receive any messages about a missing module though, just an exception when creating an Output instance. I did find that, when I switch to using ports 2+ my code worked perfectly fine, which was very strange. I was wondering if there's a reason why pins 0 and 1 would act the way they do? If I plugged my LED into either of them and connected power to my Shield base the LED would flicker several times and eventually turn off. Thanks for any help on this!

#15 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7767 posts
  • LocationNew York, NY

Posted 01 July 2012 - 02:10 PM

Hi KJ,

I wanted to follow up on this thread and see if there was any progress made on resolving the issue Jack had? I had a very similar issue with my Netduino Go and Shield Base. If I tried to create a new Output port with digital pins 0 or 1 on the Shield Base I would get a very similar exception. I didn't receive any messages about a missing module though, just an exception when creating an Output instance.

I did find that, when I switch to using ports 2+ my code worked perfectly fine, which was very strange. I was wondering if there's a reason why pins 0 and 1 would act the way they do? If I plugged my LED into either of them and connected power to my Shield base the LED would flicker several times and eventually turn off.

With the current Sheild Base (beta), we wanted to let people deploy code directly to the board as well. This means that COM1 (pins D0/D1) are currently in use a deployment/debug channel for .NET MF.

We'll be changing this default behavior in an upcoming 4.2.0.x beta. You'd still be able to deploy code C# to the early boards via Visual Studio...but you'd need to reflash the board to do so.

Chris

#16 Gorf

Gorf

    Advanced Member

  • Members
  • PipPipPip
  • 96 posts

Posted 02 July 2012 - 09:11 AM

With the current Sheild Base (beta), we wanted to let people deploy code directly to the board as well. This means that COM1 (pins D0/D1) are currently in use a deployment/debug channel for .NET MF.

Does this mean D2 and D3 are available for serial comms? (I'm not planning on deploying any code to the shield base.)

#17 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7767 posts
  • LocationNew York, NY

Posted 02 July 2012 - 03:13 PM

Hi Gorf,

Does this mean D2 and D3 are available for serial comms? (I'm not planning on deploying any code to the shield base.)

D2/D3 and D7/D8 are available or serial comms if you deploy an app to your Shield Base directly. They'll also be available for use via proxy (from the Netduino Go mainboard) shortly.

Chris

#18 Billy Propes

Billy Propes

    Advanced Member

  • Members
  • PipPipPip
  • 33 posts
  • LocationVincent, OH, USA

Posted 14 July 2012 - 04:24 AM

Hey Chris,

Just to give you another test case on the problems Jack is experiencing. I seem to be having a similar problem.

I've updated the software on my Netduino and ShieldBase both to the latest releases. The new software for the ShieldBase does indeed seem to work great. However, I am running into an issue after I run the software the first time. I am running some simple code to test the PWM as follows:

using System;
using System.Threading;
using Microsoft.SPOT;
using Microsoft.SPOT.Hardware;
using SecretLabs.NETMF.Hardware.NetduinoGo;
using NetduinoGo;


namespace Netduino_Go_ShieldBase_PWM_Test
{
    public class Program
    {
        public static void Main()
        {
            // write your code here
            ShieldBase sb = new ShieldBase(GoSockets.Socket5);
            PWM pwm = new PWM(sb.PWMChannels.PWM_0, 1, .5, false);

            pwm.Start();

            Thread.Sleep(15000);
            pwm.Stop();

        }

    }
}
The software runs great the first time around (and thereafter, as long as I don't modify the code). My problem seems to be occurring after I modify the code. For instance, in the PWM constructor, I change the frequency of 1 to 10 (to make the LED I have hooked up to it flash faster).

After I modify the code and attempt to run it, all of the lights (except the power light) go out, and my code no longer runs. As a matter of a fact, VS doesn't even wait the 15 sec before stopping the debugger. The debugger stops and the program exits almost immediately (with an exit code of 0 in the output window).

I have to unplug my Netduino Go, Restart VS, and plug my Netduino Go back in to get any code to run again. As a note, I'm running an Intel Quad Core CPU @ 2.66GHz, 2GB RAM, WindowsXP Pro. I haven't tried reprogramming my ShieldBase with the original production software (nor do I have a file containing it). But I didn't have this problem before upgrading to the ShieldBase - the PWM just didn't work before.

Any suggestions? Is there something wrong with my code or is it something else? Any help would be appreciated!

Edited by Chris Walker, 14 July 2012 - 05:50 AM.
added [code][/code] tags


#19 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7767 posts
  • LocationNew York, NY

Posted 14 July 2012 - 05:37 AM

Hi Billy,

However, I am running into an issue after I run the software the first time.

Could you try flashing your Netduino Go with the attached (unofficial) firmware? Just flash all three files using ST's "DfuSe demonstrator" program.

KodeDaemon found a flash erasing issue which could affect Netduino Go users when they flash really large apps to their boards. The "Shield Base" update is one such large app...so it's possible that this is keeping the deployment sectors from being erased properly.

The attached firmware includes a quick fix, in case you're running into that issue. This fix will also be included in the upcoming 4.2.0.1 firmware.

[If this doesn't resolve your current scenario, we'd like to debug further.]

Chris

Attached Files



#20 Billy Propes

Billy Propes

    Advanced Member

  • Members
  • PipPipPip
  • 33 posts
  • LocationVincent, OH, USA

Posted 14 July 2012 - 03:14 PM

Thanks Chris. I'm out of town right now, but I'll try the new software tonight or tomorrow and let you know my results.




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users

home    hardware    projects    downloads    community    where to buy    contact Copyright © 2016 Wilderness Labs Inc.  |  Legal   |   CC BY-SA
This webpage is licensed under a Creative Commons Attribution-ShareAlike License.