大家好!
我们的某些系统上的引导加载程序中存在一个奇数错误。 我们通过 USART 向引导加载程序发送 FW-File、下载进度显示在 LCD 上。 但在我们的某些系统中、引导加载程序会在 LCD 更新后立即崩溃并复位。 到目前为止、我们只有始终工作或始终失败的器件、我们还没有找到有时会崩溃的器件。 所有器件在技术上都是相同的、硬件没有任何差异、因此它似乎取决于组件容差。
我们的 MSP 采用3.3V 电源供电、运行频率为16MHz:
UCSCTL0 = 0x0000
UCSCTL1 = DCORSEL_5;
UCSCTL2 = FLLD__1 +511;
UCSCTL4 |= SELA2;
我们的(简化的)代码:
静态空 ParseRXData(){
//解析/验证/刷写接收到的数据块
if (NewChunk){
UpdateLCD (((U8)((NumBytes *(U32) 100)/NumBytesTotal));
_DELAY_CYCLES (51);//<-变通办法!
}
}
void UpdateLCD (u8 value){
//根据值,计算要显示的数字
_LcdWrite();
//在此处添加延迟不起作用!
}
void _Lcdwrite (void){
//写入 LCDMEM
}
他迄今所发现的:
- 使用调试器单步执行代码时、不会发生错误。 但是、由于 USART 中断、代码执行无论如何都是完全不同的
- 当使用连接的调试器运行时、它将在没有调用堆栈的情况下停止在"_DebugBreak"中、因此我们不知道崩溃的确切发生位置。 状态寄存器不显示任何故障或 NMI
- 注释掉"UpdateLCD"时、不会发生崩溃。 但是、在专用测试中测试函数 UpdateLCD 效果非常好、它也用于其工作的软件的其他部分。
- UpdateLCD 之后的__delay_cycles 似乎修复了崩溃。 必须为51个或更多周期、50个周期将崩溃。 在 UpdateLCD 中放入 delay_cycles 将不起作用
- 将 CPU 时钟降低到8MHz 似乎可以修复崩溃
那么、有什么提示如何解决这个问题呢? 到目前为止、delay_cycles 的权变措施似乎有效、但我们不知道原因。 我们不知道它是否真正修复了所有器件上的问题。
谢谢!