Hanzibal is right. Main() calls an infinite loop and never exited. The scheduler just never returned to the main thread. The interesting thing is the other threads ran fine. If I move output0.Flash() to a third thread then all the lights flashes simultaneously. So how is the Main Thread different from other threads? Also if I run the code in debug under VS then it behaves properly, despite the lights flash much slower because of the debugger communication. Is this a SDK, firmware or .NET MF defect? 

The reason I do not want to put a Thread.Sleep() is I need to monitor the input pins as frequently as possible. My actual project currently only runs under the main thread and the main loop iterates 3 times a ms. As I am adding more functionality to the program multi-threaded application will become much cleaner and easier to maintain, but I can't afford to put a 1ms sleep without changing a lot of code. Is there a way to sleep less, i.e. 1/2 ms?

I also wonder how much performance overhead does the thread scheduler take? i.e If I put 2 loop counters on 2 threads and add the counters together (a+, vs. one thread with loop counter c.  What is the ratio of (a+ : c?  I will give it a try when I have time and report.

I discovered an interesting issue while experimenting with Threading.

I have the following Main Program:

ToggleOutput is a simple class I made to toggle an output pin periodically. I tried 2 different methods to toggle:

Method 1 uses Thread.Sleep:

Method 2 uses an infinitely loop with a counter. The pin toggles every 3000 iterations:

If method 1 is used, everything works fine.

If method 2 is used, The onboard LED will flash for a second or so, then it will stop flashing, while my LEDs connected to A0 and A1 will continue to flash. The observation suggests the main thread will run for a second or so, then the scheduler will give execution cycles to thread 1 and 2, but the main thread was never given any processing cycle back to execute its operation. The workaround is creating a 3rd thread to flash the onboard LED, and in main, put Thread.CurrentThread.Suspend() to suspend the main thread.

Interestingly, if I run the program using method 2 through a debugger with Visual Studio, then everything works fine.

Full test program is attached.

I've attached the revised code to demonstrate how to recreate the problem. Exception handling code is added to confirm no exception was raised.

The same code is still running under the Netduino 2 board as I am posting.

Please help review the code and see if it is something I did wrong or if it is the hardware/firmware.

Upon further testing I found out the problem persists running from a "virgin" Plus 2 with 4.2.2.2 pre-installed. It just happened to take longer to freeze.

We have discovered however the same code running on the Netduino 2 has not yet hung after 24 hours and counting.

Both boards are running V4.2.2.2. Anybody knows the difference between two boards in design, other than the difference in the processor?

I looked at the datasheet for both [color=rgb(0,0,0);font-family:Tahoma;font-size:small;]STM32F2 and [/color][color=rgb(0,0,0);font-family:Tahoma;font-size:small;]STM32F4 and they look almost identical except the faster speed and the Ethernet interface on the F4.[/color]

[color=rgb(0,0,0);font-family:Tahoma;font-size:small;]Can someone recommend other utilities and methods to further troubleshoot the problem?[/color]

The following code Open() call thrown an ArgumentException:

   SerialPort comm1Port = new SerialPort(SerialPorts.COM1, 38400, Parity.None, 7, StopBits.One);

   comm1Port.Open();

Exception Stack Trace: 

I tried both 4.2 and 4.3 with the same behavior. It appears the SDK only allows 8 databits.

Yes we did use STDFU to completely erase the firmware

The boards are not connected to the network.

MFDeploy Device capabilities check for the working boards and non-working boards are identical.

Other than the MAC address, the boards are the same. I can't verify if the non-working boards were defective to begin with though. Those were the 1st two boards (Plus 2) we bought and we upgraded to 4.3 right after we got them. After we experienced the hang up issues we downgraded them back but that didn't resolve the problem. Then we bought another Plus 2 and a 2 to try and they work fine, on exactly the same code with exactly the same way we deploy to the board.

After upgrading to 4.3 our app would hang after a few minutes of action. After some troubleshoot we narrowed down to serial port read operation. We downgraded the board back down to 4.2.2.2 and the problem did not go away.

We created a simple test by having one netduino board to continuously send data out of an UART port, and have another netduino board to continuously read the data. Comm setting is 38400 8N1, No Handshake. We toggle some LED lights every 5000 bytes received and toggle the onboard LED light every loop 1000 iterations so we can see the status of the operations.

We tested the code on 2 "virgin" boards where no firmware changes were done - one Netduino 2 and one Netduino plus 2, and both boards ran overnight without a problem. However on a board we have done firmware changes, the board would just freeze after a few minutes of operation. We confirmed the behavior is the same on 4.2.1.1, 4.2.2.2 and 4.3.0.0 Beta.

We wrote 2 programs - One program does a simple serialPort.Read operation in the main loop (code as attached). We also tried using DataReceived event handler. Both approach makes no difference - the program would hang between 5 and 15 minutes.

We followed instructions on http://forums.netdui...-v422-update-2/. The only thing we did not do is resetting the Mac Address, as MFDeploy gave error message "Unable to erase configuration sector memory"

Anybody had the same experience and can shed some lights on this? We now have 3 Netduino plus 2 boards that are half bricked.