Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
19 years ago

Program goes back to reset address

Hello all,

I wrote my own boot loader based on Altera's example boot loader. The biggest differences are that my boot loader uses a defined address to load the program code and I use ldw instead of ldbuio.

When the program is loaded into SDRAM, the boot loader jumps to it and start executing the program code. I stepped through the code with the debugger and this seems to work.

But after a couple of instructions (don't know where exactly) the CPU jumps to the reset address or is resetted somehow.

It looks like the program is running the initialisation (default alt_main()) and craches somewhere in a interrupt routine. I don't know the exact address because when I step through the code everything works fine, but when I run the program it jumps to the reset address.

The address to the call which doesn't return when I run it is 0x02427ac (call 0x0203cfde). I don't know the code is the same for every program using the default alt_main().

I use nios2-flash-programmer to program the flash with the srec files I created.

I used elf2flash and nios2-elf-objcopy to create the srec file of the program. These are the commands and there options:

elf2flash --input=program.elf

--base=0

--end=0xFFFFFF

--reset=0

--boot=flash_header.srec

--output=temp.srec

nios2-elf-objcopy -I srec

-O srec

--srec-forceS3

--srec-len 32

--change-addresses 0x480000

--temp.srec

--final_program.srec

As you can see I used a different boot loader srec file to create temp.srec. This is because I have my own boot loader and this file contains some header information and is 32 bytes long. I checked the srec file and this all looks fine to me.

I have to change the addresses of the temp.srec file because the program must be programmed at offset 0x480000 in the flash.

So it looks like everthing should work fine, but it does not and I don't know where to look for the problem. So does anybody have any suggestions about where to look for the problem?

Regards Ronald

4 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    19 years ago

    stupid question... may you have a timer device which resets cpu on overflow (watchdog behavier)

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    19 years ago

    That's the same question I asked myself. But why would it cause an overflow when the bool loader loads the program into RAM and not when I run the program from the IDE (load it directly into RAM)?

    I use the full featured vhdl example and as far as I know it doesn't have a watchdog timer.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    19 years ago

    Ok, I solved the problem.

    I used ldw and stw to read a word from the flash memory and store it into the ram memory. But I need to use the stwio instruction to move the data to ram. This is because I need to bypass the cache. So the boot loader is working now http://forum.niosforum.com/work2/style_emoticons/<#EMO_DIR#>/cool.gif

    But there is something I don&#39;t understand. The boot loader runs a memory test, a very simple one. It stores a word on the base address of the SDRAM and load it back from that address:

    stw r_mem_test_val, 0(r_ddr_sdram_base_ptr)

    ldw r_mem_test_ret_val, 0(r_ddr_sdram_base_ptr)

    cmpeq r_compare_resul, r_mem_test_ret_val, r_mem_test_val

    But when I change these instructions to stwio and ldwio, the test fails and I don&#39;t understand why.

    Could somebody give me an explanation for this?

    thanks

    Regards Ronald
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    19 years ago

    Your first test (stw, ldw) tests your data cache, not SDRAM, so you should probably ignore it. Your second test tests SDRAM. I&#39;m not a hardware engineer, but I&#39;d try stwio, wait a few clocks, then ldwio, and see what happens. Succeed or fail, there&#39;s still probably an issue with your SDRAM.

    I haven&#39;t tried this, but it may be possible for the data cache to "cache" empty address space. So, you could be using the wrong address.