Strange C code behavior under JTAG gdb

[Altera_Forum]

Hi there, I was trying to run the following simple test program on my DE3 board; it simply copies a 8-bit PIO register for input from the DIP switch to another one for output to the green LEDs. I noticed strange behavior when running this code in debug mode under the Altera Monitor Program. When stepping through the code, it works as expected, but after hitting the "Continue" button to go into Run mode, it stops working... (If you flip DIP switches, there's no change in the LEDs...) but then, when the Pause button is hit to suspend execution, the LEDs then suddenly change to the correct value.  

 Any ideas what might be causing that weird behavior?   #define Switches (volatile char *)0x0011000# define LEDs (char *)0x0011010  void main() {  while (1)  *LEDs = *Switches; }  A hand-coded assembly language version of the program worked fine both when single-stepped and when run continuously, and the compiler's assembled C code for the loop also appears to be correct, by inspection, and the registers can be seen to be loaded with the correct addresses for the memory-mapped PIO registers before they are referenced.  The design was generated straightforwardly using Terasic's DE3 System Builder followed by SOPC Builder, following the example given in the document "Introduction to the Altera SOPC Builder Using VHDL Design," with minor modifications as needed to run on the DE3 board instead of the DE2. The following line of structural code was used to instantiate the Nios system in the top-level Verilog file for the project that was generated by DE3 System Builder:  // Instantiate our custom lights.vhd module and connect it up to board I/O  lights ( DIP_SW , 1'h1, OSC1_50, LEDG );  The constant 1 turns off the reset_n input to the Nios system.  P.S. I also tried running it under the Nios II IDE, stepping through it in debug mode, but there, it wouldn't read any new input values after the first one, and the LED states never changed. It didn't work in Run (non-Debug) mode there either. I also tried enabling the device's CPU Reset flag in Quartus and then resetting the device after loading, but that also didn't seem to do anything useful.  Thanks for any help.

[Altera_Forum]

Never mind; after re-creating the design from scratch a second time, I am no longer having any of these problems, although I am not sure exactly what it was, out of the few things I did differently, that fixed it. 

 -Mike

[Altera_Forum]

This code doesn't work if the CPU has a data cache. In that case it will read back the *switches value from the cache instead of reading the actual PIO value. 

I guess it works when stepping in the code because the code executed by the debugger invalidates the cache line that used to hold the switches values, but it was pure luck. Use the IORD/IOWR macros to have a more reliable code.