It seems the stack-trace stuff that gets printed to the debug every few seconds is causing my program to break. How can I turn it off? (also tried from external power, still had same problem)
Joe
garbage collection cannot be making your program break.
The easist way to stop those messages is to unplug the USB cable from your PC. 
Joe I see you’re not a brand NEW user (5 posts) but I have to ask - you’ve done the firmware update and have the GHI and NETMF components in and working? And your simple “test” programs like led blinky etc all worked ok?
I think you probably will need to explain what’s going on more tha you have, so we can help diagnose. What do you think the “break” you’re seeing is, what is your program doing, what are you trying to achieve and what actually happens. Have you reduced the code down to a workable size that you can share, or even if you’ve just removed all extraneous functions so that you can show a simple repro here? Have you started a new project in VS and moved over your code? (which can clear up any old projects with previous firmware versions)
So non-usb power ensures that the stack-trace-dump stuff isn’t outputted?
All I’m trying to do is receive input from a serial port and write it to a text file on an SD card (as fast as possible). And then I’m diffing the outputted file against whats sent over the serial port and I’m finding bands where data is missing.
This is the program sending data:
namespace SerialTestPC
{
class Program
{
static void Main(string[] args)
{
FileStream f = File.Open("/2010-Mar-15 14,46,36 CPU Pak viewer port2.txt", FileMode.Open, FileAccess.Read);
byte[] a = new byte[f.Length];
f.Read(a, 0, a.Length);
SerialPort p = new SerialPort("COM3", 115200); p.Open();
p.Write(a,0,a.Length);
for (int i = 0; i < 1024; i++)
p.Write(new byte[] { 0, (byte)i++ }, 0, 1);
p.Close();
}
}
}
and this is on the FEZ
public class Program
{
const int BAUD_RATE = 115200;
const int BUFFER_SIZE = 1024;
static byte[] Buffer;
static int Index;
static FileStream File;
static SerialPort Port;
public static void Main()
{
Port = new SerialPort("COM1", BAUD_RATE); Port.Open();
PersistentStorage ps = new PersistentStorage("SD");
ps.MountFileSystem();
VolumeInfo vi = VolumeInfo.GetVolumes()[0];
if (!vi.IsFormatted)
throw new Exception("Unformatted");
File = System.IO.File.Open(vi.RootDirectory + @ "\serial-test.txt",FileMode.OpenOrCreate);
while (Port.IsOpen)
{
Index = Port.BytesToRead;
Buffer = new byte[Index];
Port.Read(Buffer, 0, Index);
File.Write(Buffer, 0, Index);
}
File.Flush();
//File.Write(Buffer, 0, BUFFER_SIZE);
Debug.Print("End");
Port.Close(); File.Close();
}
}
Thanks for the help 
This is explained in the book. When you create an object but you lose the reference to your object then once the GC runs it will clear it out
It’s not actually breaking, just not working properly, there’s no dereferencing happening, nor is it throwing runtime errors because of this.
What I was originally asking was how to undefine TRACE constant. But that didnt fix my problems…
Do you have to open the comm port?
That is the whole point of the program, to log the data from COM1 to the flashcard.
Those messages can’t be disabled and there is no need to disable them at all! If you do not need the messages then just ignore them. Maybe I didn’t understand your question.
OK, so once again, what is going on when you say “it’s not working properly”. What makes you think it’s not working properly?
I did note you have the Port.Open(); on the end of your setup line - that’s why Mike has asked about that, it’s not obvious.
It doesn’t matter, the FEZ isn’t suitable for our needs anyway. Thanks a lot
Joe
Do you mind sharing why?
I would like to see an option to disable these messages. They end up dominating the Debug Output window making it difficult to see my own informative debug messages. The GC messages can be very useful but 99% of the time I would prefer to see my own debug messages without having to stop debugging to scroll up a few hundred lines.
Good point but, unfortunately, there is no way to disable these messages.
An option would be to use a serial port to send debug messages
Hi David
Did you try to right click on the VisualStudio Output window and deselect some of the options like
Step Filtering messages
Module load/unload messages
Process exit
Play around with those and if you still have problems we can try to work around.
Would appreciate your response.
HTH
-Rajesh
hi Rajesh
I tried this myself i got most of the messages cleanup, but not the GC messages cant be disabled from there.
greetings
maybe it was me, but i never really understood why the GC messages in the debug stream made the original poster’s project not work right.
I am assuming that the actual DEBUG stream was just being used to debug, and that content itself wasn’t being “scraped” for the real data. Thats where a second serial connection would come in and be used for the data transfer back to a PC app (or other host app)
I do agree though, sometimes it’d be great to be able to disable GC status updates, when you’re in a tricky debug situation. But then again maybe I just don’t use debug.print enough for it to be a big issue for me
Just out of curiosity, why is it impossible to turn off the GC messages?
Also, I too am confused as to what caused the OP’s program to break.
[quote]Just out of curiosity, why is it impossible to turn off the GC messages?
[/quote]
We would need to add something to disable GC messages, which we didn’t!
I tried to read the code to find the bug but I am not able to find anything strange but analyzing the code doesn’t give you details like stepping in the code.
The best one to give us an answer is the one who owns the code. He has the hardware and code and is able to step in code and modify the code …etc.
I also want to know why the code did brake…that if it did really brake! Sometimes users look at code but what is on the device is something else! I have seen it happen many times 
i think what your forgetting is that people use things in different ways
when i used java in doing serial connection (for the first time) on a javelin stamp i needed to use the print statements in order to understand what was actually coming on the serial connection, i found this thread looking for what that same type of seeming random output was on coming inside my serial data
even though i have an LCD screen that can show whatever i want, the serial data is too much for that 2x16 screen, so i too used Debug.Print() to output the serial data (connecting to GPS), except unfortuantely its also filled with the random garbage from the GC (see what i did there?). it just doesnt seem to make sense for it to do something that you couldnt turn off that dilutes your main connection with the FEZ. Do any other classes force you to live with random Debug.Print() statements that i wont find out until its corrupting my data? which class is it anyways?