Why NOP/few extra lines of code/optimization of pointer aliasing helps? [Fujitsu MB90F543 MCU C code] <p>I am trying to fix an bug found in a mature program for Fujitsu MB90F543. The program works for nearly 10 years so far, but it was discovered, that under some special circumstances it fails to do two things at it's very beginning. One of them is crucial.</p> <p>After low and high level initialization (ports, pins, peripherials, IRQ handlers) configuration data is read over SPI from EEPROM and status LEDs are turned on for a moment (to turn them a data is send over SPI to a LED driver). When those special circumstances occur first and only first function invoking just a few EEPROM reads fails and additionally a few of the LEDs that should, don't turn on.</p> <p>The program is written in C and compiled using Softune v30L32. Surprisingly it is sufficient to add single __asm(" NOP ") in low level hardware init to make the program work as expected under mentioned circumstances. It is sufficient to turn off 'Control optimization of pointer aliasing' in Optimization settings. Adding just a few lines of code in various places helps too.</p> <p>I have compared (DIFFed) ASM listings of compiled program for a version with and without __asm(" NOP ") and with both aforementioned optimizer settings and they all look just fine.</p> <p>The only warning Softune compiler has been printing for years during compilation is as follows:</p> <blockquote> <p>*** W1372L: The section is placed outside the RAM area or the I/O area (IOXTND)</p> </blockquote> <p>I do realize it's rather general question, but maybe someone who has a bigger picture will be able to point out possible cause. </p> <p>Have you got an idea what may cause such a weird behaviour? How to locate the bug and fix it?</p> <p>During the initialization a few long (about 20ms) delay loops are used. They don't help although they were increased from about 2ms, yet single NOP in any line of the hardware initialization function and even before or after the function helps.</p> <p>Both the wait loops works. I have checked it using an oscilloscope. (I have added LED turn on before and off after).</p> <p>I have checked timming hypothesis by slowing down SPI clock from 1MHz to 500kHz. It does not change anything. Slowing down to 250kHz makes watchdog resets, as some parts of the code execute too long (>25ms).</p> <p>One more thing. I have observed that adding local variables in any source file sometimes makes the problem disappear or reappear. The same concerns initializing uninitialized local variables. Adding a few extra lines of a code in any of the files helps or reveals the problem.</p> <pre><code>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 } </code></pre>