If you redeploy the program can you debug?
Nope. Even reflashed the firmware, redeployed, same issue.
If I remove the TE35 from the code, I can debug just fine. As soon as the TE35 inits while debugging, poof, spontaneous reboot.
I have a CP7 and the same code(minus about 3 lines for the touch differences) and the CP7 works fine(now) with the Hydra. It is just an issue with the TE35.
Update. I have a Hydra, Spider, CP7, and two TE35s.
Spider works fine in debug with both TE35 and CP7.
Hydra works fine in debug with CP7, but not TE35.
Are you using the Designer to add the TE35? Can you provide some example code for us to test to see if we can reproduce the problem? And what do you mean by cannot debug? If you deploy without debugging, does the application work?
We tested the TE35 here on our end to ensure that it will work, particularly to make sure that the touch events worked correctly.
I’m about to leave work for the day, but can take a deeper look Monday.
If I open up Program.generated.cs, put a break point on Program.Mainboard = new GHIElectronics.Gadgeteer.FEZHydra(); press F5 or hit Start, it will break on that line just fine. I then hit F10 to step over Program p=new Program(); and then use F11 to step into InitializeModules(). I then hit F10 on each one of the modules it inits, as soon as I hit F10 for this.Board_Display = new GTM.GHIElectronics.Display_TE35(10, 11, 12, 13); the board resets and even though Visual Studio thinks I’m still debugging, I’m no longer connected to the Hydra.
I went this low level because I made a breakpoint much further along and it never hit it, even though the screen showed I was in the section it should have hit that break point.
This behavior does not exist for CP7 on Hydra, nor CP7 on Spider, nor TE35 on Spider.
namespace Gadgeteer_TrayTaxi {
using Gadgeteer;
using GTM = Gadgeteer.Modules;
public partial class Program : Gadgeteer.Program {
private Gadgeteer.Modules.GHIElectronics.RelayISOx16 Board_Relay;
private Gadgeteer.Modules.GHIElectronics.UsbClientDP Board_Power;
private Gadgeteer.Modules.GHIElectronics.Display_TE35 Board_Display;
private Gadgeteer.Modules.dotnetwarrior.FlashFileSystem Board_Flash;
private Gadgeteer.Modules.elens.Sensor Board_Sensor;
public static void Main() {
// Important to initialize the Mainboard first
Program.Mainboard = new GHIElectronics.Gadgeteer.FEZHydra();
Program p = new Program();
p.InitializeModules();
p.ProgramStarted();
// Starts Dispatcher
p.Run();
}
private void InitializeModules() {
this.Board_Power = new GTM.GHIElectronics.UsbClientDP(2);
this.Board_Flash = new GTM.dotnetwarrior.FlashFileSystem(4);
this.Board_Sensor = new GTM.elens.Sensor(8);
this.Board_Relay = new GTM.GHIElectronics.RelayISOx16(9);
this.Board_Display = new GTM.GHIElectronics.Display_TE35(10, 11, 12, 13);
}
}
}
It is normal for the mainboard to reset after LCD config are loaded the first time.
This was multiple retries. Every time the TE35 gets inited with the Hydra while the debugger is attached, it resets. Does not do it with the CP7 and it doesn’t do it with the TE35 or CP7 on a Spider.
@ NXTwoThou
Can you try to remove the two modules from DotnetWarrior out of the designer and try your test again? I added the TE35, the ClientPD module, and the Relay 16 module to the same sockets in which you added them and I am not getting this debugging issue.
Was out sick yesterday. Removed the flash board and it didn’t make any difference. Still get this message every time:
Using mainboard GHI Electronics FEZHydra version 1.2
Updating display configuration. THE MAINBOARD WILL NOW REBOOT.
To continue debugging, you will need to restart debugging manually (Ctrl-Shift-F5)
namespace Gadgeteer_TrayTaxi {
using Gadgeteer;
using GTM = Gadgeteer.Modules;
public partial class Program : Gadgeteer.Program {
private Gadgeteer.Modules.GHIElectronics.RelayISOx16 Board_Relay;
private Gadgeteer.Modules.GHIElectronics.UsbClientDP Board_Power;
private Gadgeteer.Modules.GHIElectronics.Display_TE35 Board_Display;
private Gadgeteer.Modules.elens.Sensor Board_Sensor;
public static void Main() {
// Important to initialize the Mainboard first
Program.Mainboard = new GHIElectronics.Gadgeteer.FEZHydra();
Program p = new Program();
p.InitializeModules();
p.ProgramStarted();
// Starts Dispatcher
p.Run();
}
private void InitializeModules() {
this.Board_Power = new GTM.GHIElectronics.UsbClientDP(2);
this.Board_Sensor = new GTM.elens.Sensor(8);
this.Board_Relay = new GTM.GHIElectronics.RelayISOx16(9);
this.Board_Display = new GTM.GHIElectronics.Display_TE35(10, 11, 12, 13);
}
}
}
OK, but what happens after that point? Can you reattach to the debugger with mfdeploy? Then what ?
@ NXTwoThou
Try to remove the sensor that you have on socket 8 also and see if that improves the situation.
Same result.
so now can you explain the behaviour? Earlier Gus says that the first time deployment should force a restart, and your debug messages show that happening. Can you now deploy the app again and see different behaviour? What about the touch events after this, can you explain what actually goes on then?
The touch screen is working fine. All the code works fine. The beta sdk corrected the problems I was having with the Hydra. The only issue is that if I’m in debug mode it forces a restart. It’s not “first time deployment”. It’s “every time the debugger is attached”. If I just power up(either external power supply or using usb) it comes up first try. If I use “Start” in VS(2010 or 2012) it starts up, reboots(disconnecting the debugger) and then operates properly(just no longer attached to the debugger).
I’m not -needing- to debug any of my code as I already squashed all my bugs with the spider+te35 combo. But needed to point out that there’s still a Hydra+TE35 issue that needs to be looked into. It doesn’t happen with Hydra+CP7, Spider+CP7, nor Spider+TE35.
ok, thanks, that’s now clearer and it probably needs GHI to comment if it’s expected or not. Can you also do one more test for me - try debugging with mfdeploy? Force the CLR to restart and check if the same messages come up - if so, it might be that the configuration isn’t being permanently stored