Nios® V/II Embedded Design Suite (EDS)
Support for Embedded Development Tools, Processors (SoCs and Nios® V/II processor), Embedded Development Suites (EDSs), Boot and Configuration, Operating Systems, C and C++
12606 Discussions

EPCS controller booting trouble

Altera_Forum
Honored Contributor II
1,112 Views

Dear NIOS friends, 

 

I am porting a system that was developed on a (custom board) with a EP1C6 to a new board revision with a EP2C8. Both are configured with an EPCS4 device and it worked very well on the 1C6 design that was compiled and programmed with Quartus / NIOS 5.0. To fully utilize the Cyclone II potential I made the move to 5.1 and this where the trouble starts. First of all the nios2-flash-programmer refused to program a device that gave back a device identification (my EPCS reported 0x202013) and the flash programmer reported that this device had no layout data and that it could not be used. It took me a few days of debugging (I thought it could be something in the hardware) before I figured out that the programming worked perfectly well with an old EPCS device (one that did not support the RDID command). So far so good, but it worried me a little. Any of you out there than ran into the same kind of trouble? 

 

But more problems: I can now program every file I like, and the contents can be successfully verified. The configuration is loaded into the FPGA but apparently something goes wrong with the bootloader when main memory is set to SDRAM. The code starts up nicely when compiled for on-chip memory (I am sure the code is copied from EPCS, reset vector in the SOPC builder set to epcs_controller), but not for SDRAM. I know the SDRAM is working correctly, because I left the board running with memory checks overnight to be sure no problems are introduced there. Is the bootloader that comes with the NIOS kit smart enough to know where to copy the NIOS code? I noticed that the compiler is also generating an epcs_controller_boot_rom.flash in the Release folder in my project directory. Any thought how to check this? It worked fine with the 5.0 release and I am pretty sure I did the Board Description thing right... It's taking me more than a week now to get this running. Thanks.
0 Kudos
4 Replies
Altera_Forum
Honored Contributor II
285 Views

Hi Arjan, 

 

> The code starts up nicely when compiled for on-chip memory (I am sure the code is 

> copied from EPCS, reset vector in the SOPC builder set to epcs_controller), but not 

> for SDRAM. 

 

Just to be sure: you _always_ have your reset vector set to the epcs controller, but the 

problem occurs when you set .text, .data, etc. to SDRAM, yes? 

 

--Scott
0 Kudos
Altera_Forum
Honored Contributor II
285 Views

you may be programming the EPCS Device incorrectly; check out this little user-guide for commands that I personally use. 

 

http://www.fps-tech.net/docs/epcs-ug.pdf (http://www.fps-tech.net/docs/epcs-ug.pdf)
0 Kudos
Altera_Forum
Honored Contributor II
285 Views

Scott, I made sure that the reset pointer in the SOPC builder _always_ points to the epcs_controller. And the problem occurs when I assign all segments to SDRAM. That's right.

0 Kudos
Altera_Forum
Honored Contributor II
285 Views

Hi Arjan, 

 

Assuming you're doing everything the same WRT to programming the epcs device and using on-chip v. sdram, I would still be suspicious of the sdram controller/device itself. 

Is there any chance your memory tests are missing failures. E.g. -- are you using a 

data cache, but forgetting to flush/invalidate before doing the read back? 

 

> Is the bootloader that comes with the NIOS kit smart enough to know where to 

> copy the NIOS code? 

 

Yes -- basically for each elf (output) section there's an address-length-data record 

that gets programmed into the epcs. The address/length is the VMA/size from the 

corresponding section in your elf file. 

 

It would be a good idea to check your elf file (via objdump) to make sure your 

sections are where they need to be and review jdhar's document. 

 

Regards, 

--Scott
0 Kudos
Reply