Nios reboot from onchip RAM problem

[Altera_Forum]

My Nios processor runs code found in onchip memory. I had no problems running code that the Nios IDE loaded into the RAM. 

 Once I compiled the code into a hex file and then compiled the FPGA design with the onchip RAM initialized with that hex file I started to run into problems.  My main problem was that on power-up everything runs smoothly. If there is a reset of the code (such as the PCI-express issuing a reset on bootup) then my code would not run correctly.  After a lot of debugging it appears that the drivers I use from Nios do not initialize their variable space on startup. For example, the JTAG driver would start a timer alarm on power-up and after a reset it would add a second alarm to the first which interfered with my code.  My current workaround is to start from the freestanding BSP / hello world program. I then disable the JTAG driver (in alt_sys_init.c) which is the most problematic. Finally I don't enable interrupts until just before my code starts. It appears to run and reset correctly now, but I would like a more robust solution.  Is there a way to clear the entire variable space after a reset? Is there code I can use at the very beginning of the freestanding hello world code that can clear the variable space?

[Altera_Forum]

The .bss section is easy to deal with - just add code early in the startup sequence to zero it (the linker will have placed symbols at its ends). 

 The .data section is more difficult. You might manage to get the linker to place the initialisation data at a different physical address to its expected virtual address (eg at the end of the memory block instead of following the code) - in which case your startup code can copy the initialised data to its correct virtual addres. Alternatively you can detect the first load and save the .data for restoration later. You may find there are some things in .data that you'll need to move to .rodata or .bss in order to avoid the second copy.  Data private to the jtag debugger is probably much more difficult to sort our.