NIOS Cores starts executing on just loading the .sof file?? Why??

[Altera_Forum]

Hello, 

 I have a multicore system and all cores have defined separate memory space in SDARM. As I load my .sof file, some of the core starts executing. I dint even loaded the respective .elf file yet. What could be the reason???  I checked the linker script also. It shows different memory segment for each core.  Please suggest.

[Altera_Forum]

The nios cpu come out of reset with the rest of the fpga image (maybe the sopc part). 

You can expose the nios's soft reset signals and drive them from some suitable logic to delay the start of execution. Depending on how you are loading the code, you may need one of the cpus to start running after reset.

[Altera_Forum]

Hi dsl, 

 But on just loading the .sof file, how can cores start execution as they are not yet programmed. They are BLANK at this instant. One thing i am realizing through my work, If I switch OFF and switch ON my DE2 board instantly and load the latest .sof, the cores are reset and they starts executing the previous .elf file being loaded to them(before power OFF). BUT, if i keep the board OFF for approx 90 sec and than turn ON and load latest .sof, then it works absolutely fine.  As there is no way the cores should execute the previous .elf as the board was power OFF in between(means everything is erased). May sound weird. But i am facing the same issue.

[Altera_Forum]

dsl is right. The cores will start executing just after the SOF is loaded (ELF or no ELF) unless you make sure that they don't. This is actually what you want them to do. You just need to control how they behave. You could design all but one core to be held in reset. It would then be that one core's responsibility to take all of the other cores out of reset. You could have a single GPIO component with the outputs of the GPIO tied to each of the other core's resets. That GPIO could have a default value which would hold these core's in reset. Writing to the GPIO would release the core(s) from reset, but only when you want them to be released. 

 If you look at fullblown OSes (take Linux for example) this is essentially what they do as well. One core is responsible for bringing up most of the system and preparing the other cores for execution and then releasing them from reset and/or "idle" state and letting them do their thing. :-)

[Altera_Forum]

Hi Slacker, 

 Thanks for that. Now i have one more query. .sof file is just the configuration file of the system being generated by quartus. And further operation of NIOS processors depends on the application written in Eclipse. So that means, .sof is not aware of what application you are writing in eclipse or what application you want to perform by NIOS. Suppose I jus want a "Hello World" printing on JTAG UART port vis NIOS processor. But .sof is not aware of that, so how could loading a .sof can make processors print "Hello World" still I say the processor to do that by loading the application file(.elf).  I think, your above application is valid after all the application files are built into individual cores.

[Altera_Forum]

what i can observe is, the application files in the cores doesn't get erased instantly after powering off. It takes some time, maybe due to capacitance. And if the board is powered ON during that time, the cores are reset and again starts executing the same application file.

[Altera_Forum]

The nios cpu will start fetching and executing code from its reset vector, it doesn't know (or care) whether the code makes any sense. 

SDRAM contents only degrade without power, so can still be partially valid even if vcc is removed for a short time. For a production device you need to make absolutely sure that 'random' instructions aren't being executed - they might just interfere with the process that loads the actual code.  I've not looked in detail about how the JTAG debugger load and executes code. IIRC it doesn't use the reset vector, so the reset vector probably ought to point to a tight loop.

[Altera_Forum]

It really helped. Thanks a lot.

[Altera_Forum]

When I program the .sof using the Altera Monitor program, I find that the elf does not get executed. However, I start a "debug" (from Altera Monitor Program) and the click on "run", the elf starts execution. What is the reason for this? 

My understanding: The NIOS II core starts execution from reset vector after reset. We load the .text section of .elf at appropriate device (SDRAM.s1, in my case) and this is set as the reset address for the NIOS II core. So, after the elf is loaded, we need to make sure that the NIOS II core is reset for the elf to start execution. I am not clear on how to do this?

[Altera_Forum]

How are you writing the code into SDRAM? 

If (for example) you are using the PCIe slave interface, then you should expose the nios's soft reset signal to an Avalon slave and get to program that writes the code to ensure that the processor is in reset while the code is written, and then takes the nios cpu out of reset once the load is complete.