Forum Discussion

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

Unable to burn my project through the "NIOS Flash programmer"

Hi

I'm having some troubles with the above, any help would be appriciated

FYI i went through the appropriate user guide, followed it step by step and i still can not resolve this issue.

I've been working on a project for several months now (developing both hardware and software, writing with VHDL and C), i haven't learned ways to write more efficiently (memory wise), so my codes might be bigger than they should be

I'm using a EP3C55F484I7 Cyclone III, trying to program an EPCS16 device.

Programming through the quartus programmer works fine (LCD responds well, buttons and switches also), burning my SOPC (with my C code on it) on the SRAM also works well, however trying to use the NIOS flash programmer to burn it shows the following errors:

severity and description path resource location creation time id

ld: address 0x1002bd4 of blank_project_1.elf section .epcs_flash_controller_0 is not within region epcs_flash_controller_0 blank_project_1 line 0 1306360751234 464

ld: region epcs_flash_controller_0 is full (blank_project_1.elf section .text). region needs to be 9496 bytes larger. blank_project_1 line 0 1306360751234 463

ld: section .rodata [01001820 -> 0100189b] overlaps section .exceptions [01001820 -> 01001947] blank_project_1 line 0 1306360751234 465

ld: section .rwdata [0100189c -> 01002bd3] overlaps section .exceptions [01001820 -> 01001947] blank_project_1 line 0 1306360751234 466

At first i though the EPCS was too small so i used an EPCS64 instead and i keep getting these same errors.

If you guys need any further information please let me know, thanks for your time

8 Replies

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

    The linker is complaining that it cannot link the supplied objects using the constraints of the supplied 'linker script' file.

    The overlap with the '.exceptions' section might be a linker script fubar! Since it seems to be placing '.exceptions' and '.rodata' at the same address - which is probably the end of '.code' (it would be for a 'normal' link - but the linker script might be doing something else when linking for EPCS.

    I'm not sure what goes in '.expections' - might be C++ exception related (IMHO these are best avoided!)

    It might be that these errors are side effects of the initial ones. However it is difficult to very these are not simple 'program too large' errors without knowing the sizes of the sections within the object files being linked, and the addresses they are being linked to. The easiest way to find the sizes is to persuade the link to suceed (by removing the size constraints and defining appropriate base addresses to stop overlaps) and then looking at the linkers .map output file.

    If you are using the IDE tools to auto-generate the linker scripts this is probably all hard and difficult!
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    --- Quote Start ---

    The linker is complaining that it cannot link the supplied objects using the constraints of the supplied 'linker script' file.

    The overlap with the '.exceptions' section might be a linker script fubar! Since it seems to be placing '.exceptions' and '.rodata' at the same address - which is probably the end of '.code' (it would be for a 'normal' link - but the linker script might be doing something else when linking for EPCS.

    I'm not sure what goes in '.expections' - might be C++ exception related (IMHO these are best avoided!)

    It might be that these errors are side effects of the initial ones. However it is difficult to very these are not simple 'program too large' errors without knowing the sizes of the sections within the object files being linked, and the addresses they are being linked to. The easiest way to find the sizes is to persuade the link to suceed (by removing the size constraints and defining appropriate base addresses to stop overlaps) and then looking at the linkers .map output file.

    If you are using the IDE tools to auto-generate the linker scripts this is probably all hard and difficult!

    --- Quote End ---

    i see..

    i only wrote with C (no C++, i've unticked the box supporting it under the projects library options)

    are you telling me to manually set the addresses on my sopc to make sure nothing overlaps? if so i've already tried it (not sure i did it right though, it popped other errors on the console)

    by removing the size constraints you mean the ones at the projects library options? (i.e. small c library, flushing the registers etc..)
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    I'd try building something where main() is just 'return 0;' - that is about as small as things can be!

    One problem is that you don't really know what the IDE (etc) is actually doing.

    My build system directly runs gcc and ld with a linker script that contains exactly what I want.

    It might be that the '.exceptions' section contains a the interrupt code - which should be at the address specified in the sopc builder (cpu property).

    However the linker could generate a jump instruction at that location - in which case the interrupt code could be anywhere in memory.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    --- Quote Start ---

    I'd try building something where main() is just 'return 0;' - that is about as small as things can be!

    One problem is that you don't really know what the IDE (etc) is actually doing.

    My build system directly runs gcc and ld with a linker script that contains exactly what I want.

    It might be that the '.exceptions' section contains a the interrupt code - which should be at the address specified in the sopc builder (cpu property).

    However the linker could generate a jump instruction at that location - in which case the interrupt code could be anywhere in memory.

    --- Quote End ---

    i see

    this is what i get after trying to build this simple program:

    http://www.imageupload.org/thumb/thumb_51615.jpg (http://www.imageupload.org/?d=665a17cd1)

    http://www.imageupload.org/?d=665a17cd1

    can i attach anything that would help you locate the cause of this problem?
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    --- Quote Start ---

    No :-)

    and the IDE is hiding all the stuff that might help.

    --- Quote End ---

    btw thank you for your help

    i've followed to "Embedded Peripherals IP" guide to configure my EPCS controller, mapped the pins manually through the pin planner and used the following options on my system library (click to enlarge):

    allonchip.JPG:http://www.imageupload.org/thumb/thumb_53037.jpg (http://www.imageupload.org/?d=aaa4c5021)

    programming went well, however it does not seem to work.

    however, programming a .sof file through the quartus programmer and running my "c/c++ nios project" while the reset and exception vectors on the CPU are set to "onchip memory", and all system library options are as shown on the above image does work (i know it simply because my lcd is doing what i tell it to by pressing some push buttons)

    meaning i cant seem to program it in a non-volatile way..

    i've also tried programming my program code on the EPCS instead off the onchip memory in case it fades after power down and i got the errors shown on my earlier posts (here's a screeny):

    progmemonepcs.JPG:http://www.imageupload.org/thumb/thumb_53039.jpg (http://www.imageupload.org/?d=dfe632501)

    am i doing something wrong? i followed the flash programming and the embedded peripherals guides, are there any other useful guides i should be looking at?

    this is so frustrating