EPCS Controller & Altera development board

[Altera_Forum]

I am trying to implement a EPCS controller on the Altera Development board but I am having a bit of trouble. I am using of the the Altera design examples for the EP2C35 with VHDL code. The version they have defined as "small". I have increased their onboard memory to 8 KBytes. Through the NIOS II IDE program I successfully built and run the "count_binary" sample program on the development board. I then went back to the SOPC builder and incorporated a EPCS Controller into the system, regenerated and compiled (with no errors). I then tried to run the the NIOS II IDE program in excatly the same configuration with the same test program with no changes to any of the Linker Scripts and I got the following error  

 region onchip_memory is full (count_binary_5.elf section .text). Region needs to be 588 bytes larger.  I then went and changed the On_Chip_Memory to 12 KBytes and regenerated and compiled (with no errors). I then was able to successfully build and run the sample test program on the development board. (why did I need to increase the size of the on_cip memory when all I did was add the EPCS controller) 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  Can anyone please help me on this, I am really stuck. One of the things I don't understand is that this sample program is very basic and small and the Altera Development board has a EP1C64 chip on it which should have more than ample space to fit this small program ?! On my design we have a Cyclone 1C12 with a EPCS4 which we calculated after configuration should have atleast 100 KBytes left of memory for us to store our firmware code (we only 64 KBytes). What have I missed ?

[Altera_Forum]

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

[Altera_Forum]

--- 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 ?

[Altera_Forum]

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

[Altera_Forum]

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

[Altera_Forum]

--- 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:)

[Altera_Forum]

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.