Nios details from reset to main()

Hallo!

http://www.altera.com/literature/manual/mn...mnl_niossft.pdf (http://www.altera.com/literature/manual/mnl_niossft.pdf)

should mostly answer your questions.

Each program you compile has its own copy of CWP manager, unless you go out of your way to disable or remove it.

As to why you "have two of them", it depends on what you're loading up and where.

But each compiled program does get one.

-- dvb

Yes this doc is the best of the bunch, but glosses over stuff, like:

Before any instruction fetches occur, I believe there are some hardwired register settings. dvb@altera(you?) would probably know this.

I am puzzled over some execution behavior that I believe is caused by an incorrect link or initialization bug. Let me start from the beginning.

My build does not vary much from a typical Nios system in that it has 3 components. There is the onchip bootstrap, that is mainly a slightly modified GERMS. There is ubiquitous flash copy routine. And there is the application, which should be built to run from SRAM.

Looking at the objdumps, I can see that the bootstrap monitor is built for the correct onchip base address. It includes a _start label, and a jumptostart routine. It appears to correctly jump to the flash copy routine on a normal reset (or begin the GERMS monitor for a modified reset). The flash copy routine is short and built for the correct flash address. It successfully copies the code to sram and appears to successfully jump over to the application _start in SRAM. The application is built for the correct SRAM base. It includes the jumptostart routine (not executed), and the _start label marking the beginning of the ever famous nios_setup.s, which eventually hands off to main(). Sound correct so far?

Now finally, the bug. When I finally got gdb working on my target hw, I could step thru the execution of main() in SRAM, but I found that the few function calls and ISRs I had defined actually jumped to flash!? How could this be? The objdump shows that all these routines (and all the setup code) are compiled for SRAM. It should not even know about flash addresses, yet when I printf("myUserFn() is at %0X\r", ((int*)myUserFn) ); it tells me the function resides in a flash address range, not in SRAM. My vector table also contains only flash addresses.

This bug is so puzzling, it has got to be some kind of classic.

I have only just pieced together the execution flow above and I am trying verify the steps. I am thinking that the gdb simulator is the only tool that will actually allow me to step thru from reset to main(), but I have not gotten it going yet (where is sim.ld?).

Any input on the behavior, or how to get the simulator working is appreciated.

The Nios jmp instruction does not expect the register to hold the address to jump to, but rather the address divided by 2 (they are always even and this was probably done to give a larger addressable range for the 16 bit version of Nios).

As a result, the raw bit pattern for function pointers and return addresses on the Nios is the address divided by 2, not the actual address. If you want to display a function pointer as an int, you need to cast it and then double it. Data pointers are just raw addresses and can be casted to ints (or more strictly, unsigned ints) in the expected way.

Does this explain what you're seeing?

Yes, this explains it exactly. By coincidence my flash is mapped to low addresses and the sram to high. Those vector table entries just looked like they pointed to flash, now I see they are just LSR&#39;ed vectors. Now that I look at the programmers manual, I see this bit shift is mentioned a couple of places, just not in the vector table discussion http://forum.niosforum.com/work2/style_emoticons/<#EMO_DIR#>/wink.gif .

Thanks.