reset & configuration revisited

I have some custom boards (cyclone, NiosIIe 33Mhz) that exhibits strange behavior on reset (either full POR OR soft reset (DEV_CLRn)). The behavior is that the Nios sometimes executes the code at the reset address as it should, but sometimes executes code located elsewhere in memory. The problem was not obvious until multiple applications were loaded in flash. Power and clocks seem OK. All memory tests so far have passed, and once an application is running, the other apps can also be run (by jumping directly) and they all appear stable. For testing, I have modified "hello_world#1","#2","#3" builds loaded at different locations in flash. They all have have the bootstrap loader and load to the same place in SRAM.

1) Looking at the configuration signals on the EPCS1S (AS) device, I see a couple of strange things. nCS is asserted 3 times during configuration, two short pulses and one long one. The cyclone data sheet shows one long assertion. Also, DATA shows some slow rise ramping during the first two nCS assertions, but is clean after that. DCLK is clean but is active during some the data ramping where the data could not possibly be valid. Both CONF_DONE and nSTATUS behave as if all went OK. Should I be concerned about these signals, or is CONF_DONE and nSTATUS enough?

2) I notice that Quartus has an option to make DEV_CLRn a global reset. The default is no. The Nios is being reset without this enabled, but is it just the core? When would I want to enable this?

3) There are several posts about the reset signal, and using the PLL to delay reset. I do see a bunch of narrow pulses/edges on my reset (DEV_CLRn) which could be the cause of my problem. I am looking into fixing this first. The cyclone data sheet lists a max rise time for inputs of 40ns. Does this apply to DEV_CLRn as well? Is there some additional logic on this signal to make it more robust or is it just like any other input?

thanks