EPCS Controller & Altera development board

Just a couple of points/questions:

1. In SOPC Builder, where are your Reset/Exception addesses?

2. Keep in mind that the EPCS is not accessed like virtual memory.

- There's a small onchip memory for a bootloader as part of the EPCS component.

Regarding your issue, it is likely to be related to your linker script, but the source of the problem could come from SOPC Builder settings.

Best of luck,

- slacker

--- Quote Start ---

Just a couple of points/questions:

1. In SOPC Builder, where are your Reset/Exception addesses?

2. Keep in mind that the EPCS is not accessed like virtual memory.

- There's a small onchip memory for a bootloader as part of the EPCS component.

Regarding your issue, it is likely to be related to your linker script, but the source of the problem could come from SOPC Builder settings.

Best of luck,

- slacker

In SOPC Builder I changed the Reset Address to the EPCS Controller component but the exception address I couldn't change from the On_Chip Memory setting. I generated and compiled and then was able to build the "count_binary" sample program with no changes to any of the Linker Scripts (i.e. all locations set to On_Chip Memory). This time I noticed the following information :-

Info: (count_binary_7.elf) 9884 Bytes program size (code + initialized data).

Info: 2372 Bytes free for stack + heap.

Which explains where the 12 Bytes of memory is going. But I would have thought that this size program could be stored and run from the EPCS ?

However, once again, in the NIOS II IDE program as soon as I changed the Linker Script "Program Memory (.txt): " from the on_chip memory to the epcs_controller, when I tried to build I got the following error message :-

region epcs_controller is full (count_binary_7.elf section .text). Region needs to be 7012 bytes larger.

It seems that changing the Reset address didn't help!

When you stated :-

...2. Keep in mind that the EPCS is not accessed like virtual memory.

- There's a small onchip memory for a bootloader as part of the EPCS component.

From the literature I read I was under the impression that could store code in the EPCS "General-purpose memory" with what ever space was left over after storage of configuration data ? The EPCS64 configuration device is for sure big enough ? Is there some other way to tell the NIOSII IDE program to store and run the code out of the EPCS configuration device besides the Linker Scripts ? Is the IDE programing only storing the code in the boot loader section only ? If so how do I direct it to store the code into the "General-purpose memory" ?

I tried also the FLash Programmer with the changed Linker Script settings but got the same results as when I built the project directly.

Any other suggestions ?

When you stated "but the source of the problem could come from SOPC Builder settings" what setting were you referring to ? The EPCS Controller seems to have no settings that can be changed ?

Hi shmueld,

> What have I missed ?

The EPCS "device" is a just a serial EEPROM that stores a _copy_ of your

code -- just like a disk drive. So, the code needs to read from the EPCS

device into memory that the nios can access (e.g. ram, sdram, on chip

ram, etc.). The EPCS device is _not_ a parallel memory in the nios

address space -- that's what slacker means when he says, "...the EPCS

is not accessed like virtual memory."

> However in the NIOS II IDE program as soon as I changed the Linker Script

> "Program Memory (.txt): " from the on_chip memory to the epcs_controller,

> when I tried to build I got the following error message :-

>

> region epcs_controller is full (count_binary_6.elf section .text).

> Region needs to be 6700 bytes larger

Ok, here's what makes up and EPCS component:

1. An ASMI controller. This is basically an SPI controller that lets

you read and write to the physical EPCS device. A physical EPCS device

is nothing more than serial EEPROM that is accessed using the SPI

protocol. From a practical point-of-view, the difference between an ASMI

controller and a "plain-old SPI controller" are the pins you use: with an

SPI controller, you assign the signals to the User I/O pins of your

choosing. With an ASMI controller, the pins are automatically assigned

to the Cyclone AS configuration pins.

2. On chip memory. The first 256 bytes (or whatever) is a read-only

on chip memory. This memory contains boot code that initializes the

caches, then searches the physical EPCS device for application code.

First, it determines where the end of your device configuration data

is, then it looks for "section records" to read into ram/sdram. After

it copies the program in, it jumps to the program's start address.

So, setting your .text section to the EPCS controller is _not_ what

you want to do. Leave your .text, stack, etc. where you want it to

be at run time. Then, set your reset address to the epcs controller,

and finally, program your application into the epcs device.

> Any other suggestions ?

Read the embedded peripherals handbook -- the sections on the

EPCS Controller and SPI controller. Then read the flash programmers

guide.

Regards,

--Scott

Scott's right. You can store your code in the EPCS, but you cannot _run_ your code from there. By telling the IDE to link your .text section into the EPCS controller, you are pointing it at the small onchip memory that is part of the controller.

If you want to store code in this device, you have to program it using the flash programmer.

- slacker

--- Quote Start ---

Scott's right. You can store your code in the EPCS, but you cannot _run_ your code from there. By telling the IDE to link your .text section into the EPCS controller, you are pointing it at the small onchip memory that is part of the controller.

If you want to store code in this device, you have to program it using the flash programmer.

- slacker

--- Quote End ---

1. How did you know if I set the .text to EPCS controller, the executable code(.text) will stored in EPCS controller on-chip memory? Did you read it in any document?

2. Is it possible to point the .text to unused area of EPCS(after configuration image & software application).

3. Can we set the .text to external memory instead of on-chip memory? Because the text size is bigger than On-chip ram size.

Thank you:)

To read EPCS (for boot) you need some code.

This code is included the the quartos EPCS block - probably so that the address of the registers can determined (a fixed offset from the program counter).

So only the reset vector needs to point into the EPCS controller memory. Apart from that you should ignore the fact that it contains memory.

That memory block is actually a PITA. You get it even if you don't want to boot from EPCS.

It also forces you to allocate an instruction cache - which you might otherwise not need if all your code is in tightly coupled instruction memory.