我正在尝试修复在富士通MB90F543的成熟程序中发现的错误。到目前为止，该程序已经运行了近10年，但人们发现，在某些特殊情况下，它在开始时无法做两件事。其中之一至关重要。
在低级和高级初始化（端口、引脚、外设、IRQ 处理程序）之后，通过 SPI 从 EEPROM 读取配置数据，状态 LED 打开片刻（为了打开它们，数据通过 SPI 发送到 LED 驱动器）。当这些特殊情况首先发生并且只有第一个功能调用几个EEPROM读取失败时，另外一些应该打开的LED不会打开。
该程序是用C编写的，并使用Softune v30L32进行编译。令人惊讶的是，在低级硬件初始化中添加单个__asm（"NOP"）就足以使程序在上述情况下按预期工作。只需在优化设置中关闭"指针混叠的控制优化"即可。在不同的地方添加几行代码也有帮助。
我已经比较了（DIFFed）编译程序的ASM列表，用于带和不带__asm（" NOP"）的版本以及上述两个优化器设置，它们看起来都很好。
Softune 编译器在编译过程中打印多年的唯一警告如下：
W1372L：该部分放置在 RAM 区域或 I/O 区域 （IOXTND） 之外
我确实意识到这是一个相当普遍的问题，但也许有更大视野的人能够指出可能的原因。
你知道是什么导致了这种奇怪的行为吗？如何找到错误并修复它？
在初始化期间，使用几个长（约20ms）延迟环路。尽管它们从大约 2ms 增加了，但它们没有帮助，但在硬件初始化功能的任何行中，甚至在函数之前或之后，单个 NOP 都有帮助。
两个等待循环都有效。我已经用示波器检查过了。（我添加了LED在之前打开和之后关闭）。
我已经通过将SPI时钟从1MHz减慢到500kHz来检查时序假设。它不会改变任何东西。减速到250kHz会导致看门狗复位，因为代码的某些部分执行时间过长（>25ms）。
还有一件事。我观察到在任何源文件中添加局部变量有时会使问题消失或重新出现。初始化未初始化的局部变量也是如此。在任何文件中添加几行额外的代码有助于或揭示问题。
void main(void)
{
watchdog_init();
// waiting for power supply to stabilize
wait; // about 45ms
hardware_init();
clear_watchdog();
application_init();
clear_watchdog();
wait; // about 20ms
test_LED();
{...}
}
void hardware_init (void)
{
__asm("NOP"); // how it comes it helps? - it may be in any line of the function
io_init(); // ports initialization
clk_init();
timer_init();
adc_init();
spi_init();
LED_init();
spi_start();
key_driver_init();
can_init();
irq_init(); // set IRQ priorities and global IRQ enable
}
可能是许多事情之一，但有两个浮现在脑海中。
定时。
也许等待的时间不足以稳定电源，并且并非所有内容都与时钟同步。NOP 让一切恢复同步。
对准。
也许NOP使您的指令在硬件预期的32位或64位边界上对齐。（我们过去经常在大型机汇编器上这样做，因为 IO 操作通常期望事情在双字边界上）。
问题解决了。它是由一个微不足道的错误引起的。
EEPROM的nHOLD和nCS信号不是在MCU复位后立即初始化的，而是在首次使用EEPROM之前初始化的。结果他们是0的，所以活跃。这意味着已选择 EEPROM，但等待等待。同时，使用 SPI 的其他传输已开始。在 8 个 CLK 脉冲中的 6 个之后，EEPROM 的 nHOLD I/O 引脚被初始化并调高。EEPROM不再处于保持状态，因此它为另一个外设输入数据的最后两位。EEPROM上的每个后续操作都发现它没有同步CLK和MOSI。
当我添加NOP或其他任何东西时，nHOLD 0->1边沿的时刻被转移到最后一个CLK脉冲之后。现在CLK-MOSI是同步的。
我所要做的就是初始化所有EEPROM的SPI线，在在 MCU 复位后立即执行特定的 nHOLD 和 nCS。