Nios reset behavior

I am trying to understand the low level startup sequence on a custom Nios board. When the Nios (3.2) resets, what determines where it fetches its very first instruction? Is it always from the onchip bootstrap area or is this configurable? I don't have the OCI so I assume I can't just step thru from reset on my target (with gdb).

As I understand it, SOPC(4.0) compiles my custom bootstrap and Quartus (4.0sp1) adds this code to the pof, but not to the application srec. I am confused that the objdump for the bootstrap shows it is compiled for my SRAM base, not the onchip area. The Nios manuals say the code is not generally relocatable so this does not seem right. I don't see how to fix this base in the Nios dialog - it appears to be set correctly.

TIA

Reply to
tns1
Loading thread data ...

In SOPC builder you set the Reset Location in the Nios More tab.

This is where the system will reset to.

I always set this an internal ram that holds either Germs or my program. That program can load a larger program out of flash and then jump to it. (or whatever you want it to)

The new NiosII has fancier automatic boot options but I haven't used it for that yet.

Ken

Reply to
Kenneth Land

Thanks. I see where I can pick the reset location. My configuration is just as you describe - a bootstrap routine onchip, and an app that gets copied from flash to external sram before execution.

My earlier statement about the bootstrap base address was wrong - the base address is correct for this onchip code image.

However, there is a bug in the way either my bootstrap or app gets built, that causes the application to jump from sram to flash addresses for any function call in main() (ISRs too). The base address for my app is correctly set to sram, not flash.

I believe the problem has to do with the initialization code before main(), either the routines that set up new stack frames and the CWP handler. To track down this bug I have been trying to make use of gdb (no jtag port for OCI) for either my hw target or the cpu simulator target. I'd like to step thru the init stuff. Using gdb for target hw debug does work, but so far I can't step thru the init stuff (it locks when stepping into flash - no surprise).

Has anyone gotten the nios cpu simulator to work under gdb? I can load an image and source but I can't step. I can't find the sim.ld script that is mentioned in the gdb docs.

Kenneth Land wrote:

Reply to
tns1

I don't know. *that* part :) has always worked for me. Let me just describe what I do and maybe you will see something.

This is NiosI BTW.

  1. Small bootloader code in onchip ram at the reset location. This gets built and placed there during the SOPC generate and QII build process. In SOPC onchip ram contents I select build bootloader.c

  1. bootloader.c wakes up and checks if I have any srec data in the unused portion (well unused isn't the correct word, but the non-harware configuration portion) of the asmi. I think I used the midway point of my

4Mbit asmi chip. Would/should work the same for any flash.

  1. If it finds some then it blindly processes each srec by blindly memcpy'ing the srec data wherever it says it goes. (The srecs addresses are set during the build/link/creation of the srec file that has been copied to the asmi chip)

  2. I'm a little fuzzy here since I wrote this a few months back, but I believe the last srec contains a start address and I jmp there and boom - I'm booted and running. (do a seach for srec on google and you'll find a/the spec for srec's)

If it should work but doesn't try lowering your cpu clock and see if it works then.

Ken

for

Reply to
Kenneth Land

Reply to
tns1

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.