FEZ Raptor won't debug, Hydra will

Archive
1

I am attempting to deploy a simple blinker program to my FEZ Raptor. VS2013 will deploy, but fails to attach the debugger. Here are the final output window messages:

Assemblies successfully deployed to device.
Restarting interpreter…
Attaching to device…
Waiting for device to initialize…
The debugging target and the debugger engine failed to initialize because of unspecified device errors.
The debugger engine thread has terminated unexpectedly with error ‘Could not reconnect to the debugging target after rebooting it.’.

The program does not start on the board. If I reboot the board via the Reset button on it, my program will start an begin blinking the LED, but of course I have no debug connection.

It should be noted that I have been using a FEZ Hydra for a project for a very long time and it works fine. I’m using the same USB port, cable, and DP Power module as I did for the Hydra. If I go back to the Hydra it works fine.

I’ve verified via FEZ Config that my TinyBooter and TinyCLR versions are 4.3.6.0. Interestingly, FEZ Config is seeing an intermittent connection to the device. It will output " Failure - Device is not connected or not responding." when I click the “Check device for update” button. If I click the button immediately after this failure, it will work. Then I can click it again, and it fails. There is no pattern to it - totally intermittent. And again - I have an extra power source plugged in on my DP board, and it is connected to the D socket (socket 8). My USB cable, port etc are all good - if I switch to the Hydra board it is all fine.

Any ideas on what’s going on here? Here is the code also. Thanks!

public partial class Program
{
private bool on;
void ProgramStarted()
{
var t = new GT.Timer(250);
t.Tick += Blink;
t.Start();
on = true;
}

    private void Blink(GT.Timer timer)
    {
        Mainboard.SetDebugLED(on);
        on = !on;
    }
}
2

Maybe “t” goes out of scope and gets destroyed too fast on the raptor. On the hydra it might be slow enough to linger long enough to behave differently. Try making it global instead?

1 Like
3

no debugging in VS, yes, I totally understand where you’re coming from. I’d do as @ mtylerjr says and promote t outside ProgramStarted() as a first go, but second can you try re-connecting to the device with mfdeploy once you reset it and the LED flashes start? That should work successfully… I too think it’s speed related, but I can’t suggest why. How about you throw a 2sec thread.sleep in at the start of ProgramStarted and see if that affects the behavior at all ?

1 Like
4

I’ve seen this problem myself before and now always make any timer in ProgramStarted global.

1 Like
5

Can you please update latest 4.3.7.7?

6

Moving the timer instance to class level does fix it.

Thanks all for pointing out my noob mistake. Interestingly, the code as I posted it works fine on my Hydra. I assumed that the timer was kept in scope by the dispatcher, so I didn’t worry about it. But clearly, the Raptor handles it differently - and I think to be honest more correctly as the timer should be scoped at the class level.

Thanks everyone!

7

Also, I have it working only on VS2012. It seems 2013 still gives the error. I’m not in a position to try the beta software at this time, so I’m sorry @ Dat, I won’t be able to update it. Hopefully someone else will be able to verify this.