C#程序导致MFDeploy无法ping通的问题
//=====================================================================
//TITLE:
// C#程序导致MFDeploy无法ping通的问题
//AUTHOR:
// norains
//DATE:
// Thursday 05-May-2011
//Environment:
// .Net Micro Framework Porting V4.1
// Keil MDK 4.02
// STM32F103ZE Redcow Board
// Visual Studio 2010
//=====================================================================
为了测试编写USB驱动是否正常，编写了一个C#程序，其完整的代码如下：
namespace HelloWorld { public class Program { public static void Main() { Debug.Print("Hello, World!/n"); Debug.Print("It's the first C# application in .Net Micro Framework!/n"); } } }
这段代码看起来没什么问题，用VS2010也能正常下载，并且从串口中也能看到打印出来的字符串。但奇怪的事情就此发生了，自从成功下载该程序，并且正常运行之后，我的板子插到电脑上虽然可以枚举，但通过MFDeploy的Ping指令，却经常无法正常通讯。如果用Bus Hound软件来查看，发现PC端发送一个OUT包之后就卡死了，如图所示：
如果将NAND上的C#程序给擦除，那么一切又恢复了正常。这究竟是怎么一回事呢？
通过MDK的断点调试，会发现代码一直在执行Systick中断函数，而查看Systick的寄存器，发现reload的数值非常小，如图所示：
造成频繁执行Systick中断函数的原因是否源于此呢？通过MDK来强制更改NVIC_ST_RELOAD寄存器的数值为0x00FFFFFF来试试。结果不出所料，Bus Bound监控到USB数据又开始交互，MFDeploy也不再假死，而检测到板子为TinyCLR了！
转回来想想，为什么Systick的Reload的数值太小，导致MFDeploy假死呢？原因很简单，Reload是每次systick中断的间隔，而这个时间太小，很可能在刚执行完systick中断函数的时候，下一次中断又发生了，从而导致主线程的代码没有获得CPU时间执行！
原因找到了，那么我们该如何解决这个问题呢？首先我们来看看Systick的中断函数。一般来说，根据.NMF的示例代码，我们的中断函数无非如此：
void ISR(void *pParam) { g_TicksLastRead = CounterValue(); if(g_TicksLastRead >= g_TicksCompare) { // this also schedules the next one, if there is one HAL_COMPLETION::DequeueAndExec(); } else { // // Because we are limited in the resolution of timer, // resetting the compare will properly configure the next interrupt. // // You mustn't comment the source code, or it would not boot normally. SetCompareValue( g_TicksCompare ); } }
这个中断函数逻辑很简单，如果当前的ticks大于要比较的ticks值，就执行HAL_COMPLETION::DequeueAndExec()函数。我们进到该函数看看。因为该函数比较大，有一些东西并不需要我们了解，所以下面罗列的是缩减后的主要部分，如下所示：
void HAL_COMPLETION::DequeueAndExec() { ... HAL_COMPLETION* ptr = (HAL_COMPLETION*)g_HAL_Completion_List.FirstNode(); HAL_COMPLETION* ptrNext = (HAL_COMPLETION*)ptr->Next(); if(ptrNext) { ... HAL_Time_SetCompare( ptrNext->Next() ? ptrNext->EventTimeTicks : HAL_Completion_IdleValue ); ... } }
从中可以看到，该函数其实会调用HAL_Time_SetCompare来设置下一次的中断时间。但如果我们使用MDK单步调试，却会惊讶发现，该函数一直没有被调用，因为ptrNext一直为NULL！如果再仔细点，在还没执行C#程序之前，ptrNext不是为NULL的！
根据经验推测，问题就出在于C#程序。具体点，问题在于C#的Main函数返回了！因为C#的Main函数返回，导致Node的结点被释放，于是ptrNext就为NULL。如果此时又刚好Systick的间隔很小，代码又因为ptrNext为NULL而不执行HAL_Time_SetCompare函数，那么最终结果就是：不停地发生Systick中断，而无瑕执行主线程代码！
原因找到之后，可能大家想到的最简单的解决方式就是在C#的Main函数中执行一个死循环，如下所示：
namespace HelloWorld { public class Program { public static void Main() { Debug.Print("Hello, World!/n"); Debug.Print("It's the first C# application in .Net Micro Framework!/n"); while(true); } } }
结果没错，这样更改之后，的确一切都正常了。似乎一切都很美好，不是么？但是，这样的健壮性是不够的，因为我们无法确保做应用的程序员能够遵守这个约定。而万一他们忘记的话，那么结果将是灾难性的：因为USB已经无法PING通，更谈不上下载程序，所以做应用的程序员无法凭一己之力来挽回自己的错误。除了你，.NMF的移植者，通过MDK来设置Systick的Reload寄存器，让CPU跑到正常的轨道上，除此以外，再无它法。
为了避免这情况，我们可以将中断函数修正一下。我们自己来检测ptrNext，如果它为NULL的话，那么我们手动调用HAL_Time_SetCompare函数即可，如下所示：
void ISR(void *pParam) { g_TicksLastRead = CounterValue(); if(g_TicksLastRead >= g_TicksCompare) { // this also schedules the next one, if there is one HAL_COMPLETION::DequeueAndExec(); //If the ptrNext is NULL,it wouldn't call HAL_Time_SetCompare() in DequeueAndExec() function //which means the main thread may not get the time to run when the systick reload value is very small and //systick interrupt occurs frequently. So I reset the systick reload value here by calling HAL_Time_SetCompare function HAL_COMPLETION* ptr = (HAL_COMPLETION*)g_HAL_Completion_List.FirstNode(); HAL_COMPLETION* ptrNext = (HAL_COMPLETION*)ptr->Next(); if(ptrNext == NULL) { //0x0000FFFFFFFFFFFFull is used by the HAL_Completion_IdleValue variable which defined in the completions.cpp file. HAL_Time_SetCompare(0x0000FFFFFFFFFFFFull); } } else { // // Because we are limited in the resolution of timer, // resetting the compare will properly configure the next interrupt. // // You mustn't comment the source code, or it would not boot normally. SetCompareValue( g_TicksCompare ); } }
经过这么一更改，那么引发MFDeploy无法响应的问题不再存在，我们也不用再担心应用程序员忘记最后写死循环啦！