Timers stop running on G30HDR. Not due to garbage collection

I have discovered a strange problem with Timers on the G30HDR board. I have an application that needs to read analog inputs periodically (not super fast, a couple times a second at most). However, after working for about 1 hour the timer event stops firing and the inputs are no longer read.

I have read about similar problems where there is no reference to the Timer object and it gets garbage collected even though it is still running. That is not the problem here.

I started by using a System.Threading.Timer, which exhibited the problem described above. I have also tried a simple infinite “while(true)” loop with a “Thread.Sleep(1000);” statement at the end, and I have the same problem.

I have even taken all of the code for my specific application out and can recreate the problem with the simple test code included below. When I run this, the output is as shown below the code. After iteration 4264 the infinite loop stops being executed. This always occurs at 6/1/2011 1:11:34 AM. Oddly after the output stops, if I hit pause in Visual Studio, I find that the value of “DateTime.Now” in the debugger has been reset back to 6/1/2011 00:00:00, and counts up again from there. I don’t know if that is related but it seems like it could be.

Can anyone tell me what is going on?

public static void Main()
		for (int t = 0; t >= 0; t++)
			Debug.Print(t + "\t  " + DateTime.Now + "\t  Free RAM = " + Debug.GC(false));
	catch(Exception exception)

0 06/01/2011 00:00:08 Free RAM = 33768
1 06/01/2011 00:00:09 Free RAM = 33528
2 06/01/2011 00:00:10 Free RAM = 33528
3 06/01/2011 00:00:11 Free RAM = 38712
4262 06/01/2011 01:11:31 Free RAM = 38712
4263 06/01/2011 01:11:33 Free RAM = 38712
4264 06/01/2011 01:11:34 Free RAM = 38712

We are looking into this immediately

@ Gus - Thanks!

In the mean time, use a thread to handle your sensor readings.

I have a system where I am reading 16 analog inputs and I do this in a thread instead of a timer. Just remember to let your thread yield with Sleep…

@ Dave McLaughlin - Thanks. I have actually tried this approach and it does not work either. Eventually the call to “Thread.Sleep()” never returns, and the loop is never executed again. I know that sounds crazy. I need to do something that doesn’t depend on time at all…

@ DarrenUtd - I have seen this a long time ago and it was a timer overflow not being handled properly. Give us a bit of time, we will get this sorted out. No worries :slight_smile:

@ Gus - Thanks. I’m looking forward to a solution.

I’ve been playing around with the numbers, and I found something interesting. The 1 hour 11 minute 34 second time that the timers work for corresponds to 4294 seconds. The value of “Cpu.SlowClock” on the G30 is 1 MHz. So 4294 seconds is 4,294,000,000 clock ticks, which is 2^31.9997 :open_mouth:


@ DarrenUtd -

It is fixed for next release. Sadly to say that there is no workaround until next release.


@ Dat - That is very unfortunate. Do you know when the next release will be? I have a product that I am selling to a customer in a few months that depends on it.

Also, exactly which products are affected by this? All G30-based? Any others?

@ DarrenUtd - only G30 is effected and the fix should be available next week.


I appear to experience this issues on fez cobra 3…timer fails after a while.

@ anthonys - unlikely. Please test with a simple program.

@ Gus - What form will the fix take? Will I be able to update my existing hardware? Any news on the timing?

Also, I was going to purchase a G30TH module. I have it in my cart, but should I hold off until it is fixed and will arrive to me updated?

The update will be included in our sdk. Just run FEZ config and the rest is done for you magically.

You can buy anything you want and update later. All updates are free.

The fix is being tested and will be released shortly.

Just to confirm, this is fixed in the recently released NETMF 2016 SDK Pre-Release 1?

If so, I will install that right away. I ask because this issue wasn’t explicitly mentioned in the change log that I noticed.

@ DarrenUtd - The fix is in that pre-release.