Slow "bursty" performance when running Stand Alone SW on target board

[Altera_Forum]

When running the SW application directly on the Target Board some part of the GUI (upper part of a twin statusbar using uC/GUI) appears immediately, then there is several seconds where nothing happens, then one of the slots are filled with data, then there is another pause, then the lower part of the statusbar appears. ... When the app finally is up and running the response to push button interrupts are bursty in the sense that the first two clicks gets handled properly (e.g. shifting focus in a dialog box) while the next clicks hangs for a second or so.  

 When running the same app from the Nios II IDE tool, be it a debug version or a release version, everything runs smoothly. The app starts fast and there is no problem with button behaviour in dialogs etc.   From the documentation in Nios II SW Developers Handbook v.11.0 it states that - boot from flash configuration :  When the reset address points to a boot loader in a flash memory. The boot loader initializes the instruction cache, copies each memory section to its virtual memory address (VMA), and then jumps to start ... The default Tcl script chooses this configuration when the memory associated with the processor reset address is a flash memory and the .text section is mapped to a different memory (for example, SDRAM)."    In the BSP Editor under linker script - Linker Memory regions - Our reset entry points to ext_flash while the .text entry in Linker Section Name points to SDRAM memory. (Also .bss, .heap, .rodata, .rwdata and .stack points to the same SDRAM memory)  (Using the Flash Programmer tool we use the boot_loader_cfi.srec when programming for Stand Alone. )   This should make the boot laoder / boot copier copy the program from flash to SDRAM and run the application from SDRAM, but because of the slow bursty behaviour when running stand alone we suspect the program still runs from FLASH and that chuncks of program and/or data are copied to RAM when needed !? Could this be the case !? And that when running from the tool the program gets stored in SDRAM and therefore runs fast !?    Any suggestion to what may cause this strange behaviour are welcomed !  Please advice ...

[Altera_Forum]

No if the .text section points to the SDRAM, then your software can't directly run from the flash. You will have a bootloader and the software will be copied to RAM. 

Is your application writing anything to the JTAG UART? If yes try to disable all those printfs, I discovered with some drivers that printing to the Jtag Uart while there was no terminal running on the other end could stall the CPU sometimes.

[Altera_Forum]

Hi Daixiwen 

 I commented out all my printf´s and voila - problem solved. Great help ! Thank you very much !    Best regards KE