Shield Base Firmware v4.2.0.1 (beta 1)
#1
Posted 18 June 2012 - 02:08 PM
#2
Posted 18 June 2012 - 02:08 PM
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.
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
#3
Posted 18 June 2012 - 05:46 PM
Twiiter: https://twitter.com/Gutworks
#4
Posted 18 June 2012 - 08:39 PM
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
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
Posted 18 June 2012 - 10:59 PM
Jack,Can't get the shield base to light up an LED either.
Which LED are you refering to? My blue socket led is working. There is no LED on the shield base itself.
Chuck
#7
Posted 19 June 2012 - 01:10 AM
#8
Posted 21 June 2012 - 05:40 PM
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
Posted 21 June 2012 - 08:43 PM
#10
Posted 21 June 2012 - 08:47 PM
#11
Posted 21 June 2012 - 10:57 PM
The error you're getting...
...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.Assembly: NetduinoGo.ShieldBase (0.1.0.0) needs assembly 'GoBus' (1.0.0.0)
Error: a3000000
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
Posted 22 June 2012 - 04:02 PM
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: a3000000Jack
PS: I am happy to a have Netduino chat - but I am in the UK so don't make it too late!
#13
Posted 23 June 2012 - 05:44 AM
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
Posted 29 June 2012 - 10:32 PM
#15
Posted 01 July 2012 - 02:10 PM
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.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.
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
Posted 02 July 2012 - 09:11 AM
Does this mean D2 and D3 are available for serial comms? (I'm not planning on deploying any code to the shield base.)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.
#17
Posted 02 July 2012 - 03:13 PM
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.Does this mean D2 and D3 are available for serial comms? (I'm not planning on deploying any code to the shield base.)
Chris
#18
Posted 14 July 2012 - 04:24 AM
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
Posted 14 July 2012 - 05:37 AM
Could you try flashing your Netduino Go with the attached (unofficial) firmware? Just flash all three files using ST's "DfuSe demonstrator" program.However, I am running into an issue after I run the software the first time.
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
Posted 14 July 2012 - 03:14 PM
0 user(s) are reading this topic
0 members, 0 guests, 0 anonymous users