Strange C code behavior under JTAG gdb

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.