I am working on a commercial application which will need to run without a PC. Whenever the debugger is inactive (Visual Studio is not actively debugging) my prototype (built on a FEZ Raptor) slows down massively, especially when handling exceptions. I have tried compiling it as Release and disabling all Debug.Print calls.
Is there some way to disable ALL debug communications, including the Exception stuff, whenever a debugger is not found?
This is a real problem, and I would really appreciate any help I can get. I have PCBs in production right now, and a rather important project is really counting on this system being functional in 2 weeks.
This will happen when the system tries to send debug messages but there is no receiver. Unfortunately, there is no automated easy to remove them. You need to remove debug.print from your code.
I’ve wrapped Debug.Print into a function that I can disable with a constant. I no longer call Debug.Print from anywhere in my code other than there, and call the disable-able method instead.
So even with no Debug.Print calls anywhere, the debugger still sends a bunch of data any time an exception is thrown. I can’t disable that.
Edit: Updating to 4.3.2 (QFE2) now. Was using 4.3.2 (RC2 - Beta).
@ bigtwisty - When exceptions are thrown, they essentially call Debug.Print internally. I’m not sure of any way to disable that. Do you get a lot of exceptions being thrown? Is there any way to reduce that number?
The device is an automated exerciser intended to support Design Validation Testing on a BLDC controller my team is designing for a client. It is intended to run multi-day test scripts putting the controller through its paces while logging any faults. I am using exceptions to indicate certain fault status that may occur in the field. These conditions absolutely cannot lock up the software as we will lose valuable data.
Even if I attempt to write code that doesn’t throw exceptions in normal course (requiring a substantially different software approach) I still cannot guarantee that there will NEVER be an exception thrown. All I can do is handle exceptions properly in code.
If NETMF causes even temporary lock-ups when exceptions occur even when they are handled in software it really is not production ready. This sounds like a pretty big problem with NETMF, or the GHI implementation of it for any serious production environment.
Isn’t it an option to force the device in Serial mode (LMODE pin) and install a RLP serial (COM1) handler that simply returns without doing anything?
Another thought… Is this MF 4.3 specific? maybe going back to MF 4.2
@ bigtwisty - For applications with high performance requirements, it is not generally good practice to use exception handling for anything other than unexpected software faults. It is very resource expensive to “unwind” the stack when an exception occurs.
@ Gus: It is bad enough to worry me in a situation where testing costing $10k+ could be adversely impacted. Automotive testing is not cheap…
@ Robvan: That is something worth looking into. Do you have anywhere you can point me for directions?
@ Mike: That is probably good advice, which I will take into account in the future. I was using some custom exceptions to pass back info on what went wrong for logging purposes. I suppose I could use a “out string fault” parameter or something instead, but that will take some writing and would make things much less intuitive.
Update: As you probably expected, updating to QFE2 did not fix anything.
@ bigtwisty - is it a concern that it maybe worse later or it is a problem now. My understanding that this causes a delay but not significant for most needs. I am just trying to understand better so I can help you in finding a solution.
And switching to COM debugging will surely take care of this as recommended by the community.
[quote=“bigtwisty”]@ Robvan: That is something worth looking into. Do you have anywhere you can point me for directions?
[/quote]
pin PA25 (MODE) is used to initialize the board to use USB or Serial mode. Boot the device with this pin low and see how it effects performance.
Further, make your debug.print conditional instead of using a variable. This way non of the debug print will be included in your release code.
public static class DebugHelper
{
[Conditional("DEBUG")]
public static void Print(string msg)
{
Debug.Print(msg);
}
}