CIII/EPCS design configures and programs but does not start

[Altera_Forum]

Hi, 

I have a design with EP3C40 and EPCS64. I create flash files with:  sof2flash --epcs --compress --input=logic.sof --output=logic.srec elf2flash --epcs --after=logic.srec --input=software.elf --output=software.srec cat logic.srec software.srec > all.srec  I then program the EPCS64 with:  nios2-flash-programmer --epcs --base=0x40000800 all.srec  It all programs and verifies fine. I power cycle the board and the processor doesn't come up. However, if I do:  nios2-flash-programmer --epcs --base=0x40000800 --go  then it starts, so obviously it programmed the EPCS correctly, the FPGA configured at start and it loaded the software. It just didn't start.  My reset vector points to the base of the EPCS device. Tools are Quartus 10.1 SP1 and NIOS IDE 10.1 SP1.  I've done exactly the above on other devices before with no problem but this is my first CIII design. Any clues?  Thanks, Mark.

[Altera_Forum]

Hi Mark 

I do nearly the same with a CIII and it works. Compare my steps to yours, although the differences are (apparently) irrelevant.  1- sof2flash --epcs --input=logic.sof --output=logic.flash  2- elf2flash --epcs --after=logic.flash --input=firmware".elf --output=firmware.flash 3- nios2-configure-sof --cable='USB-Blaster [USB-1]' logic.sof 4- nios2-flash-programmer --cable='USB-Blaster [USB-1]' --epcs --base=0xa00000 logic.flash 5- nios2-flash-programmer --cable='USB-Blaster [USB-1]' --epcs --base=0xa00000 firmware.flash

[Altera_Forum]

Hi, 

Thanks for the reply. Our steps are basically the same and I get the same with yours. Same also with the flash programmer GUI in the IDE. I double checked that the FPGA is configuring properly from the EPCS device and it does (clocks and test points all come up as expected). I also read back the contents of the ROM in the EPCS SOPC component to verify that it's the same as the ciii boot loader in nios2eds/components/altera_nios2/boot_loader_epcs_sii_siii_ciii.srec. It matches byte for byte. It's like the call at the end of the boot loader isn't calling the correct address.  Can you tell me what your reset and exception addresses are in your NIOS CPU? My reset address points to the EPCS so that it starts at the boot loader, which seems the correct thing to do.  Mark.

[Altera_Forum]

The nios2-flash-programmer has a bug in it, 9.1SP2. When you program EPCS with it, it does not work. Create programming file using Altera Stand Alone Programmer, then burn the file into EPCS.

[Altera_Forum]

OK, but I'm using 10.1 SP1. Is the bug still in this? 

When you say to use the stand-alone programmer I assume you mean the Quartus SAP. But isn't this the same code as the 10.1 SP1 release?  Thanks, Mark.

[Altera_Forum]

Could this bug have been resurrected? 

http://www.alteraforum.com/forum/showthread.php?t=22441

[Altera_Forum]

Yes, it looks like it. I have experienced the nios2-flash-programmer. Using it to program EPCS, NIOS II does not boot properly. I have a DE2 board. It is proven to me that nios2-flash-programmer has a bug. 

 One more thing, stay with uncompressed programming file. The compress one may have problem too. I have not fully investigated the issue yet.  So, bottom line. I use SAF to program EPCS with uncompressed pof.

[Altera_Forum]

--- Quote Start ---   Can you tell me what your reset and exception addresses are in your NIOS CPU? My reset address points to the EPCS so that it starts at the boot loader, which seems the correct thing to do.   --- Quote End ---   Hi Mark My Reset address is the EPCS base address, while exception address is the base address of onchip code memory + 0x20. I use 9.0 sp2 and I was not aware of the reported bug. I used nios2-flash-programmer but I never had problems. I use compressed bitstreams, too.

[Altera_Forum]

--- Quote Start ---  So, bottom line. I use SAF to program EPCS with uncompressed pof.  --- Quote End ---   OK, tried that. It doesn't work either. I create a HEX file of the software offset to the end of the FPGA data. I create a POF file starting with the FPGA data and followed by the HEX file. The software complains that they overlap by one byte (they don't). So I shift the HEX data by one byte to make the SAP happy and generate the POF. It generates the POF, which successfully programs the FPGA but doesn't start the software in the same way as before.  Mark.

[Altera_Forum]

Hi Mark. 

I think you definitely have a problem with the Nios 2 bootloader. Since you initially said you made the same with other devices (and it worked fine!!), it could be that your are using the bootloader of the wrong device, because you did a copy and paste with old project files. Or maybe bootloader image has been corrupted because of any other reason. The bootloader is usually stored in a epcs_controller_boot_rom.hex file in the fpga project. It is generated from the bootloader source files in Altera directory C:\altera\<your version>\nios2eds\components\altera_nios2\boot _loader_sources\boot_loader_epcs_bits_<device_fami ly>.S I'd recommend you check the hex file and possibly regenerate it from the source files.  I attach for your convenience my CIII bootloader file. It should work for you, too. Execute a fpga MIF update, flash into epcs and let me know if this solves your problem.   Regards Cris

[Altera_Forum]

Presumably the boot loader has the address of the rom and memory compiled into it - they could be wrong ...

[Altera_Forum]

--- Quote Start ---  Hi Mark. I think you definitely have a problem with the Nios 2 bootloader. I'd recommend you check the hex file and possibly regenerate it from the source files.   --- Quote End ---   Yeah, I wondered the same thing. The project was from scratch, so there's no old cruft in there. However, just to be sure I wrote a little program to read back the bootloader bytes from the EPCS component. It matches byte for byte with the ciii hex file in the Quartus directory, so is good I think.   --- Quote Start ---   I attach for your convenience my CIII bootloader file. It should work for you, too. Execute a fpga MIF update, flash into epcs and let me know if this solves your problem.   --- Quote End ---   Thanks. I'll give it a go. Mark.

[Altera_Forum]

--- Quote Start ---  Presumably the boot loader has the address of the rom and memory compiled into it - they could be wrong ...  --- Quote End ---   Possibly, although as I wrote in the original post if I power up the board, connect the JTAG lead, and do:  nios2-flash-programmer --epcs --base=0x40000800 --go  then the software starts fine. This suggests to me that the boot loader has copied the code to the RAM correctly but has not performed the final call to the start of the software properly.  Mark.

[Altera_Forum]

Okay, I figured out what was going on. My board has a reset circuit that holds everything in reset until the supplies are stable. However, it turns out it doesn't monitor the SDRAM supply. So I think what was happening was the FPGA would configure and start the boot loader which would then copy the software into the not-quite-ready SDRAM. I added a delay to the release of reset and now it comes up reliably. 

Mark.

[Altera_Forum]

The SDRAM will need several (refresh?) cycles [1] after poweron before it will hold data. The SDRAM controller probably does these - but they'll take a few clocks. 

 [1] Well EDO DRAM needed them, which meant the software had to perform them before doing anything else.