When I run a certain piece of software in Visual Studio the G30 stops responding in Fez Config in both modes despite appearing in device manager correctly. This is repeatable and has happened to four of my devices so far and I can’t seem to recover them or pin down the exact cause. I’ve added all the code in a bit at the time and seems something to do with referencing the GHI.Hardware library.
Known issue, updated your firmware to the latest sdk. Let us know if this solves the issue.
I already have installed the SDK from .NET Micro Framework – GHI Electronics. Is there anyway to recover these boards?
@ Daithi - If something in your code is locking up your device so that you can’t communicate with it, it is likely something that runs in the very beginning of your program. Your only option at that point is to reflash the firmware by entering the GHI Bootloader mode.
Once you reflash again, I would deploy a new small program that just blinks an LED to verify that it works then return to figuring out what is breaking in your program.
Did you update firmware using FEZ config?
I checked with FEZ config and it said I had the latest firmware already installed.
I think the problem is something to do with the size of the libraries or using two Signal Generators. It seems that, that’s when my problem started.
This is what I see when I try to reflash.
@ Daithi - To reflash the G30, once you enter the GHI Bootloader which it appears you have, you need to run “Loader Update” under the Advanced menu in the upper left.
@ John - I’ve just tried that and it produces an error saying it cannot be updated via the serial port.
@ Daithi - Don’t select the serial port on the first screen. Just open FEZ Config and immediately go to the Advanced menu.
@ John - When I put the device in boot loader mode it connects as a usb serial port. When I select Loader Update it presents me with this screen.
@ Daithi - You should be able to click next and proceed with the update.
@ John - When I try to do that it just uses com1 and fails with this window.
@ Daithi - Looks like your device is COM57 but you picked COM1.
@ Gus - It looks like you are correct. I could’ve sworn I’d selected 57 but I’ve now reflashed all six devices. Now I need to get to the bottom of why they’re stopping i nthe first place and how to work around the code problem.
The problem occurs as soon as I try to call Set on a second Signal Generator object. When SGR.Set(false, time1, 0, 2, true); is commented out it runs as expected and when it’s included the device stops and must be reflashed.
This is the test code I’m running:
using System;
using System.Threading;
using Microsoft.SPOT;
using GHI;
namespace MFConsoleApplication1
{
public class Program
{
public static void Main()
{
Debug.Print(Resources.GetString(Resources.StringResources.String1));
uint[] time = new uint[] { 1 * 10, 1 * 1 };
uint[] time1 = new uint[] { 1 * 10, 1 * 1 };
GHI.IO.SignalGenerator SG = new GHI.IO.SignalGenerator(GHI.Pins.G30.Gpio.PA8, false);
SG.Set(false, time, 0, 2, true);
GHI.IO.SignalGenerator SGR = new GHI.IO.SignalGenerator(GHI.Pins.G30.Gpio.PA3, false);
SGR.Set(false, time1, 0, 2, true);
int Counter = 0;
while (true)
{
Debug.Print(Counter.ToString());
Counter++;
if (Counter > int.MaxValue - 10)
{
Counter = 0;
}
Thread.Sleep(1000);
}
}
}
}
@ Daithi - We will take a look at the code you posted and let you know what we find.
@ John - I’ve already switched to using PWM which was the original plan. I just had a bit of trouble with that to start with and put the SignalGenerators in until I could get back and sort it. I do think there’s something wrong with the behaviour using SignalGenerators but there’s no need for it on both of those pins.
@ Daithi -
Frequency is too high that causes system too busy.
Using pwm if you need high frequency instead of SignalGenerator.