Cyclone IV GX EPCS booting trouble

[Altera_Forum]

Hi Everybody, 

 With my colleague we are working on the Cyclone IV GX custom boards. Now we are succeeded to develop an application for FPGA and NIOS. The problems have started when we tried to flash the EPCS device with the SOF and ELF. To come closer our testing set: 

1. Terasic DE0-Nano CYC IV E 
2. Our custom board CYC IV GX 

  We have prepared easy test qsys which basically implements: 

• NIOS II Economy 
• SDRAM controller 
• System ID 
• JTAG UART 
• EPCS FLASH CONTROLLER 
• PIO 

  The sopc file is attached.  We have assigned correct pins for the EPCS conduit and configuration part of our HW is also attached. In the NIOS II EDS we have created hello world project with led blinking (connected to the PIO).   After flashing .sof and .elf using the Flash Programmer GUI and cycling the power of our custom board the leds are not blinking.   Now the strange part, if we will reproduce these steps (from blank new project) for Terasic DE0 Nano and program corresponding .sof and .elf it is blinking after power-up. No we are not able to see any difference in the software part neither in the qsys setting. The NIOS II C code is the same one.   Can anybody help please? Or maybe some tips?

[Altera_Forum]

Now we have discovered another thing which could could cause the troubles.  

 The .flash file which is corresponding to the NIOS .elf file contains some headers inside. The first 4Bytes of the content describes the length of data which are stored and the following 4Bytes contains the address where should be the data copied. Please tell me if this is not true. After this 8B header there is data contents and it contiunes with next header and so on.  On the DE0 - working, the first flash header contains some length and the address of SDRAM (where should be data copied)  BUT  On the custom board with Cyc IV which is not booting correctly - the first flash header contains lenght but the adress is 0x0000 0000 (but the SDRAM has some another address).  We thing that the bootloader is OK, but it copies the section to the faulty address.  Now the question is, what we have to change to get correct .flash file. Is the problem in the elf2flash or? We are using the Flash Programmer GUI to generate flash files.

[Altera_Forum]

Hello Johndos, 

Unfortunately I cant help you, im pretty new here, so I am seeking help here,  my question is, suppose you want to get back to the original bootlaoder of the DE2 115 board , how can you do that ?   Thank you, and I hope you solve your issue.

[Altera_Forum]

So I have a good news, which could help all other members with similar problem. We had contacted Altera official technical support and we got reply which has solved our issue. I am pasting here the reply from support. Anyway, it was very hidden problem... almost impossible to solve with very deep knowledge of the Altera compilation processes and so on. 

 For your information, <installation>\ip\altera\sopc_builder_ip\altera_avalon_epcs_flash_controller\em_epcs_qsys.pm (line687) indicates that:  · CYCLONE and CYCLONEII will be using /ip/altera/nios2_ip/altera_nios2/boot_loader_epcs.srec  · STRATIXII, CYCLONEIVE and etc will be using /ip/altera/nios2_ip/altera_nios2/boot_loader_epcs_sii_siii_ciii.srec  · For V series device will be using /ip/altera/nios2_ip/altera_nios2/boot_loader_universal.srec     Thus, this can explain that rd11122013_865 is only applicable to Cyclone V (or V series) because different device is using different bootloader.     During my investigation, I found that Cyclone IV GX is missing from the bootloader check statement and this could be the cause of this issue.     Here, I would like to suggest a workaround as below:  Go to line# 703, <installation>ip/altera/sopc_builder_ip/altera_avalon_epcs_flash_controller/em_epcs_qsys.pm, add the device “CYCLONEIVGX” into the second condition check. before:  ($device_family eq "CYCLONEIVE")) after:  ($device_family eq "CYCLONEIVE") ||  ($device_family eq "CYCLONEIVGX"))    I have also attached the modified em_epcs_qsys.pm file for your reference; you may compare and replace the file. The fixes of this issue will be included in ACDS 14.0. At the meantime, I have also file a KDB on this issue and the workaround will be publish soon.