Remote System Update : Arria V (EPCQ 256), failed to configure the application image

[Altera_Forum]

Hello,  

 The remote system update failed to configure in Arria V.   Quartus version : 14.1 FPGA : arria v FLASH : epcq 256  Assignments used : set_global_assignment -name STRATIXV_CONFIGURATION_SCHEME "ACTIVE SERIAL X1" set_global_assignment -name STRATIXII_CONFIGURATION_DEVICE EPCQ256 set_global_assignment -name STRATIXIII_UPDATE_MODE REMOTE set_global_assignment -name IP_TOOL_NAME "ALTREMOTE_UPDATE"  I have 2 images, Factory kept at 0x00000000 and Application at 0x1000000.  The module RSU IP is well updated with the AnF (datain is 0x0000001 and param is 0b101) and the application address (datain is 0x1000000 and param is 0b100) before triggering the reconfig.  Once the reconfig is launched, I have observed nios2-terminal connection ceases. When I tried to debug the Application soft NIOS IDE, the debugger shows up that there is no valid sof or nios.   With a LED which is wired to "conf done", I have confirmed that the configuration of the application image failed. I couldn't make out where is the mistake.   I hope my method of generating Application image is correct  conversion sof2flash:  sof2flash --input="../FPGA_APP_std_5AGXMB1G4F35I5.sof" --output="../FPGA_APP_std_5AGXMB1G4F35I5_tmp.flash" --epcq --verbose  nios2-elf-objcopy -I srec -O srec --change-addresses=0x1000000 "../FPGA_APP_std_5AGXMB1G4F35I5_tmp.flash" "../FPGA_APP_std_5AGXMB1G4F35I5.flash"  programming:  nios2-flash-programmer "../FPGA_APP_std_5AGXMB1G4F35I5.flash" --cable="$JTAG_PROBE_NAME" --base=0x23002000 --epcs --sidp=0x230050a0 --id=0 --timestamp=1436179333 --device=1 --instance=0 --program --verbose  Could you please tell me if I forget anything special for EPCQ-256 config?  Further to that I tried to verify the image written in the flash with  nios2-flash-programmer "FPGA_APP_std_5AGXMB1G4F35I5.flash" --base=0x23002000 --epcs --device=1 --instance=0 --verify --verbose  It returns 0..  Thanks in advance for your help..

[Altera_Forum]

Interestingly, I also found that the conf_done is showing up error when the re-config is triggered with the application address 0x0. Normally it should load the Factory FPGA, right?

[Altera_Forum]

--- Quote Start ---  Interestingly, I also found that the conf_done is showing up error when the re-config is triggered with the application address 0x0. Normally it should load the Factory FPGA, right?  --- Quote End ---    Hello,   While debugging with the AS interface of the FPGA, I had found that the SPI sends the address as 24 bits even though the EPCQ used is 256.   For example, to know the behavior at FPGA configuration , I tried an address 0xABCDEF98 and confirmed with signal tap that the address is written correctly at the data_in port of the RSU module!  Surprisingly, the data in SPI bus is 0x0b, 0xAB, 0xCD, 0xEF 0x00 ... Seems the EPCQ 256 controller communicates 24 bit address, instead of 32 bit.   Does this mean that I forgot to use some options for the FPGA, to enable 4 byte address access of the EPCQ-256 ??   Thanks in advance for your advice.

[Altera_Forum]

Hello, 

 The analysis of the wavefroms at SPI interface reveals that in the Application mode, the EPCQ device started sending the configuration image data to FPGA just after 3 bytes of address were received, instead of 4 bytes of address. In both the cases the dummy cycles were 4 clocks. I guess there is a difference in the Address Configuration in the Application mode; the EPCQ controller is in 4 bytes mode whereas the EPCQ device is in 3 bytes.   To confirm this, I have tried a function call "epcs_enter_4_bytes_mode" (obtained from the epcs_commands.c provided in HAL) at NIOS side before the reconfig command, with the belief that it would enable "4 Byte Address Mode" corresponding to 4BYTEADDREN (defined in the Datasheet of EPCQ device). The result was positive. The FPGA at Application Mode configured well (the blinking LED @ Application comfirmed the config)  Can anyone please tell me :  If 4BYTEADDREN mode is causing the issue, why doesn't it make a problem in configuration of FPGA after POR?   Is there any "Non Volalite Configuration register" (NVCR) to activate this mode premenantly?   How can I write "4 Byte Address Enable" in this NVCR? Is there any special NIOS2 command or JTAG operations available? Please share us, if it exists.   Has anyone modified the boot_loader_epcq256_bits_cv.s to obtain a customised boot loader?

[Altera_Forum]

--- Quote Start ---  Hello,   While debugging with the AS interface of the FPGA, I had found that the SPI sends the address as 24 bits even though the EPCQ used is 256.   For example, to know the behavior at FPGA configuration , I tried an address 0xABCDEF98 and confirmed with signal tap that the address is written correctly at the data_in port of the RSU module!  Surprisingly, the data in SPI bus is 0x0b, 0xAB, 0xCD, 0xEF 0x00 ... Seems the EPCQ 256 controller communicates 24 bit address, instead of 32 bit.   Does this mean that I forgot to use some options for the FPGA, to enable 4 byte address access of the EPCQ-256 ??   Thanks in advance for your advice.  --- Quote End ---    After analysing the wave forms of the SPI interface of EPCQ in the Application mode, I have found that the EPCQ device started sending the configuration image data to FPGA just after receiving 3 bytes of address, instead of 4 bytes of address. In both the application and factory mode, the dummy cycles were 4 clocks. It seems, there is a difference in the Address Configuration in the Application mode; the EPCQ controller is in 4 bytes mode whereas the EPCQ device is in 3 bytes.   To confirm this, I have tried a function call "epcs_enter_4_bytes_mode" (obtained from the epcs_commands.c provided in HAL) at NIOS side before the reconfig command, with the belief that it would enable "4 Byte Address Mode" corresponding to 4BYTEADDREN (defined in the Datasheet of EPCQ device). The result was positive. The FPGA at Application Mode configured well (the blinking LED @ Application comfirmed the config)  Can anyone guide for:   If 4BYTEADDREN mode is causing the issue, why doesn't it make a problem in configuration of FPGA after POR?  Is there any "Non Volalite Configuration register" (NVCR) to activate this mode premenantly?  How can I write "4 Byte Address Enable" in this NVCR? Is there any special NIOS2 command or JTAG operations available for this?

[Altera_Forum]

I have resolved my issues. May be my findings help some one else in the future.  

 The address send by the EPCQ controller was correct in the SPI mode:   The hardware only stores the 24 most significant bits of the address, and then transmits 0 for the least significant byte. This is what is described on page 8-38 of the device handbook: https://www.altera.com/content/dam/altera-www/global/en_us/pdfs/literature/hb/arria-v/av_5v2.pdf  Why there is a mismatch in address mode even though the Factory configures well.  The answer is the default boot loader. Even though there is an NVCR corresponds to the 4 BYTE Address Mode, the operation code 4BYTEARREX (EPCQ 256 Datasheet) overrides this value. I have observed the presence of 4BYTEARREX in SPI interface when the default boot copier runs. So the solution is to force the EPCQ256 device in 4BYTE ADDRESS MODE before reconfig either by epcs_enter_4_bytes_mode call or some other method.

[Altera_Forum]

Hi maddyn, 

 which EPCQ controller are you using? The Legacy EPCS/EPCQx1 or the Serial Flash Controller?  Jens

[Altera_Forum]

--- Quote Start ---  Hi maddyn,  which EPCQ controller are you using? The Legacy EPCS/EPCQx1 or the Serial Flash Controller?  Jens  --- Quote End ---    We have used EPCS/EPCQx1 flash controller.