MichaelAtSamraksh
commented
9 years ago I think developers who has examined the Timer subsystem are frustrated. I know that I have been frustrated ever since I was forced to debug it while looking into something else.
Please do me a big favor and use full function names and at least short file names, otherwise I don't know what the parent post references. For instance, do you mean:
- file netmf_timers.cpp function
CPU_Timer_SetCompare(Timer,CompareValue) - file stm32f10x_tim.c function
TIM_SetCompare3(TIMx, Compare3) - file netmf_advancedtimer.cpp function
STM32F10x_AdvancedTimer::SetCompare(compareValue) - file eMote_Time_functions.cpp function
HAL_Time_SetCompare(CompareTicks)
Thank you for referencing the commit used for the tests.
Nathan-Stohs
AnanthAtSamraksh
ChrisAtSamraksh
Running Chris' app in #282 (with 800ms timers instead of 100ms), I logged all
SetCompare()requests at the timer low-level to memory from start of TinyCLR (no TinyBooter) until the program gets deadlocked in the execution loop. Then I dumped the array with GDB. This was in debug mode with-O2.I don't know if this is related to #282 , I think it is, but either way this needs attention. Data Formatting is difficult in this medium, I have a spreadsheet if desired.
First column is the actual compare time requested. Second column is difference from last time requested. Last column is the same delta but in milliseconds.
Unfortunately I did not log the current time which could have been illuminating.
Time starts at 0, so all of these requests for times of 4 billion+ are pure garbage. Actually, only 5 of the 317 calls are directly attributable to the program (C# user timers). The rest is junk, minus perhaps a few OS requests.
I was running the logic analyser at the same time, and I counted 5 transitions on the IO. There are exactly 5 lines similar to:
Which I assume are the 800ms user timers, and the only timers that should be running.
It is extremely difficult to debug other problems until this mess is taken care of, and this is almost certainly where our performance bleed is coming from.
After the last timer, no further timer requests are made. It is unknown what happens at the end, if we lose a callback, lose a time, or we never set it up for other reasons. When we deadlock, it is in the C# interpreter, not in sleep or otherwise apparently involving the timer. Difficult to say what its waiting for.
I have not looked at other optimization levels. Likely they look different.
EDIT: This was in master on 4eb63cb926feb01946afa07515e6d8438a45af7b