Domino deploy/debug errors (stupid mode)

NETMF & Gadgeteer
1

To deploy or not to deploy; that is the question…
My FEZ and I will be flying along nice and smooth, when all of a sudden, it enters what I call “stupid mode”.

After entering stupid mode, will I be able to deploy to my Domino? Maybe, maybe not… If it does deploy successfully, will I be able to debug it? Maybe, maybe not…

Various ‘diagnostic’ messages:
[ul]
“Unable to communicate with device USB:USBizi” ----- Why not? What happened?
"… cannot attach debugger engine!" ----- Why not? What happened?
“Deployment error: failed to (re)connect debugger engine to debugging target. The debugging target and the debugger engine failed to initialize because of unspecified device errors. The debugger engine thread has terminated unexpectedly with error ‘Debugger engine could not attach to debugging target.’.” ----- Why? What happened? Which unspecified device error should I try to fix first?[/ul]

I usually just begin pushing F5 and ‘n’ (to answer the ‘deploy failed, continue?’ dialog) rapidly, until, maybe, eventually, sometimes, it snaps out of stupid mode.
I also intermingle reset buttom spamming amidst all of these attempts. One or more of the above usually ‘recovers’ from stupid mode, however how many and of which type(s) is newly randomized each time.

The only thing I haven’t tried (yet) is kicking/burning/smashing it. I belive this would ‘fix my problem’ by causing me to buy a different model that doesn’t include this feature.

2

I should point out that I’m mostly kidding and/or just frustrated about this.
If I deploy a blank solution to the Domino, it will 99.9999% deploy and debug just fine. There is an error in my code and I just hate commenting, uncommenting, commenting, uncommenting, etc., etc., until it suddenly “works” again. “Works”, as in, I can now, actually debug my code?!!

public static void Main()
{
  try
    {
      DoANYThingFFS();
      Thread.Sleep(Timeout.Infinite);
    }
  catch (Exception ex) { Debug.Print("Exception: " + ex.Message); }
}

[ul]If the debugger fails to attach, does Debug exist?
Is the Debug class always 100% globally accessible (and .Print()-able), even with no listeners attached?[/ul]

3

I can’t answer your rant, I mean question… if you have one.

The comms that I understand goes on is that the debug host (Visual Studio) attempts to communicate to the debug target (Domino in your case). If it can’t communicate, then it whinges. Sometimes it’ll get to a state where it won’t detect a failure and will wait for a long time. (and there’s an issue with some of the drivers that can cause the PC to restart if the debugger attaches but you reboot the device - but that’s not related to your issue right now). Once it can communicate, it’ll send your code, send a reboot, and reattach to the debugger.

If you have a heavily loaded up application that has little time to allow the debugger to attach, then you can get into a state where deploying won’t work, and it will need you to intervene and reset the app. Some times people suggest a period of inactivity at startup (say a thread.sleep() ), or some switch-based check to progress past initialisation that means there is lots of time available on the processor for the debugger to attach. To me it sounds like you’re hitting this kind of issue occasionally, and if you had a sleep at the start of your app, then reset the device just before you try to deploy, you might get a better result - has to be worth a try anyway in my view!

4

Yes Debug object is there even for release build.

I suggest to move

Thread.Sleep(Timeout.Infinite);

Out of the try/catch block to the very bottom of your main function.

That way even if there is an exception you application is still running.

5

Process of elimination via commenting yielded a null reference exception in a constructor.

Just to be clear, please confirm:
[ul]The Domino is running my code (and crashing) after the FEZ reboots, but before the debugger has time to attach
The start-up delay you suggested should allow the debugger to attach more reliably
With the debugger properly attached before any and all other user code, it would have notified me, helpfully, about the null-reference[/ul]

This makes sense; thanks!

6

Correct.

1 Like
7

‘Try’ is the first line of every single method.
I have a 5 second delay at startup, some more later, and more again everywhere else.

while (stupidMode)
{
  StartDebugging();
  if (Domino.FeelsLikeDeploying & Domino.FeelsLikeDebugging) break;
}
WhatWasIDoingHalfAnHourAgo.TryToRecall();

I’ve noticed a couple things experimenting with stupid-mode:
[ul]It will almost always ‘Deploy.’ If it doesn’t on the first try, a single reset will almost always fix it.
It will almost always fail to deploy when I 'Start Debugging’
When it eventually chooses to deploy, it will almost always fail to attach the debugger
If/when it eventually chooses to attach the debugger, it does so instantly and begins loading symbols. Also, the first line of Main() is reached after the debugger is already attached successfully, with or without a delay[/ul]

In trying to track this down, I put Debug.Print() everywhere. Is it possible that the debug output from the Domino (from previous, running, deployment) is interfering with the debugger attachment?

8

Can you show us all of your real code?

9

@ Architect - More investigating; discovered MFDeploy yesterday…

It seems that, in most instances, when Visual Studio is failing to deploy and/or debug, USBizi is actually alive, well, and responsive. When I connected MFDeploy and rebooted, I discovered that my code did almost nothing other than generate exceptions. Even though I’ve “handled” them, they were quickly overwhelming the CLR and causing allocation failures for anything further. I can understand this confusing it. Additionally, I also reorganized my code to first initialize everything, then do nothing except blink an LED, indefinitely, until a button is pushed, which helped track down the errors.

I’m not new to threading, debugging, or exception handling, but I’m used to (on PC) being told 100% of the time when something is wrong.
It seems to me that:

while (!Debugger.IsAttached)
{
  WaitForDebuggerToAttach();
  if (optionally & TakingTooLong) { Ping/ReReboot/Timeout(); }
}

should be a separate process between deploy and debug.

[ol]Try to connect <-- If ‘Debug’ initiated, could send EnterDebugMode() first, rebooting the device in ‘debug mode,’ which would block user code execution until the Debugger reattaches, or the device is reset.
Deploy <-- VS doesn’t even bother to reboot the device when I ‘Deploy;’ only when I 'Debug’
Reboot <-- Could be ‘DebugReboot’ if I initiate with ‘Debug’ and not just ‘Deploy.’ Again, it should wait for the Debugger to attach before running user code.
Reconnect
Attach debugger[/ol]

Is that lump of code in the USBizi firmware? I doubt my ability to tweak it, but I would really like the Debugger to work. With it attached first and foremost, I would have caught the exceptions and been able to fix them within minutes. I’d call that “Freakin EZ”; currently, it is less EZ than it should be.

10

I could, but it wouldn’t help. I already know my code is the culprit, because I can deploy empty projects and LED blinkers all day long. I’m just frustrated that the Debugger doesn’t attach first. Maybe I’ve just been spoiled by coding on PC…

11

Rather than being able to comment one thing and re-run to test, like I would on PC, I have to comment everything and then uncomment one thing at a time. Just different; will take some getting used to…

12

It is hard to advise without looking at the code.
Here is one rule that is good to follow always - “think small”.

13

@ Architect - More frustration…

I used MFDeploy to erase and reboot my Domino. Then, I unplugged and replugged it. Then, I hit reset button, just in case.
I get a ping response but VS will fail to deploy all day long.

[ul]The odd thing is that, if it is going to fail to deploy, it does so before it can connect and ‘query’ the assemblies on the device, to even know if they need updating.
Sometimes, if I ‘Rebuild Solution’, the same code that had already been deployed, and hasn’t changed since, will magically be able to deploy, but not attach the debugger.
Sometimes, rebuilding the solution will not work. When it doesn’t, I have to push spacebar somewhere in code and then it will deploy one additional time.
To deploy again, afterwards, I must add another space and ‘rebuild’.
Sometimes, although a project will build successfully, a project that links it will have a yellow warning icon next to the reference and fail to compile. I delete the reference, re-add it, and can build.[/ul]

There is definitely a problem in my code but, worse, theres a problem with the mechanism that’s supposed to tell me what my problem is.
My issue appears to be on the VS side of things, possibly the NETMF interpreter/compiler is throwing an exception but not reporting it?!?!?
I have no clue; where should I start? Is there a hidden verbose mode setting somewhere, maybe via command line?

P.S. - My code has pretty much not changed for many of these cycles, now. It will succesfully deploy and debug, just not often, and never more than once in a row. When it does connect the debugger, I generate no exceptions, and the code performs as expected, perfectly so.

14

Can you show us your code?

15

At some point, which I don’t recall, I opened this in 2012 which was not meant to work with 4.1, but happens to… sometimes…
2010 debugs every time, without fail.

Quote me please, so I can mark it as the answer.

16

Good. I am glad you got it sorted out. :smiley:

17

Actually with 2010, rather than the Domino going unresponsive for a random amount of time/resets, now I get BSOD in Windows, instead, and reboot. I’m pretty sure this is worse; I’m used to rebooting quarterly and I’m over quota for the next 13 years now. On the other hand, 2010 is fast to deploy and debug 95% of the time so I’ve made progress as well. Got daisylink PulseInOut module running on shared hardware I2C bus now. Automatically avoids fixed-address I2C modules like gyro.

I read about a similar issue with 4.1. Is 4.2 better? Why can’t the Domino run it? Could I help fix/make it?

18

Domino can’t run 4.2 as GHI have not made the decision to invest in the Premuim USBizi firmware for 4.2. Currently their focus is the other newer Premium boards (G120 module) and the Cerberus family of OSHW boards. That’s not something you can assist with (besides noting your preference to keep USBizi moving forward) as the source is closed GHI proprietary.

The reboots are related to the GHI debuggable driver that is loaded. The WinUSB driver that 4.2 provides an option for is supposed to assist here. This is the bit I noted way back in my earlier post but it wasn’t relevant at that point - seems more relevant now. There are some steps you can do to minimise this; don’t disconnect and reconnect the Fez (or use the reset button) while it’s in the “deploying…” stage. If you are in that point and it looks hung, cancel the deployment and wait.

19

The Domino was the cheapest; on sale. I so wish I’d got the cerb or hydra. I think I’ve learned a lot more this way though. I’ve still got a Cerb40 I haven’t even touched yet.

Thanks

20

So the other thing I’d point out (while GHI are asleep :)) is that there’s a good reason they’ve not spent any time on this - the have a very strong product in 4.1 on USBizi, and many many (many many) happy commercial customers, as well as happy enthusiasts, with well-proven and feature rich firmware. They see moving to 4.2 as not giving any significant benefit to those customers (for instance, the networking changes in 4.2 are pointless on USBizi since it uses the Wiznet 5100 chip’s IP stack). And honestly, there are differences that would be great to get access to but in most cases a bit more code gets you to the same place as 4.2 would, so you really aren’t that limited - but you will have to remember that there’s two different netmf versions you’ll need to use.