Programmable Devices
CPLDs, FPGAs, SoC FPGAs, Configuration, and Transceivers
Announcements
Need Forum Guidance? Click here

Search our FPGA Knowledge Articles here.
18983 Discussions

EPCQ remote update using HPS and Nios II on board with Cyclone V SoC

Sergey81
Novice
412 Views

Hi,everyone.

Is  it possible to upgrade EPCQ using HPS and Nios II and Serial Flash Controler? In Remote System Upgrade over UART based on Nios II Processor with EPCQ it is shown how to upgrade EPCQ using UART interface on the board and Nios II-based qsys system.  In Booting Altera SoC FPGA from Network using TFTP and NFS we see how to download files into DDR RAM using tftp server on the host PC and u-boot commands. The idea is to download .jic-file (or another type of config file) into RAM and load it into EPCQ through Serial Flash Controller. If it's possible I don't need a UART interface, just Ethernet interface which is needed anyway in my case.

0 Kudos
4 Replies
EricMunYew_C_Intel
Moderator
331 Views

You can perform remote system upgrade using Nios II and GSFI IP.

You can refer to below for GSFI IP:

https://www.intel.com/content/dam/www/programmable/us/en/pdfs/literature/ug/ug-gen-sfi.pdf


Sergey81
Novice
316 Views

I'm working with Generic Flash Access reference design (actually I adapted it for Arrow Sockit board since I don't have Cyclone V E FPGA Development Kit). Arrow Sockit is equipped with N25Q256. I'm not sure if it's the same as EPCQ256 or there is any difference between them. Anyway, when I start Nios2 program from reference design it reads 0x1019ba20 as device ID and classifies flash as EPCQ256. However, I get usually 0x64 as status register value and program prints "Sector protection failed due to error in setting status register", "Check datasheet to find out". I've tried changing mask_sr2 value to 0x64, in this case program runs till the end, the read value differs from written value (0x8020ab0 instead of 0xabcd1234, for example).  Sometimes I got 0x83 as status register value, but again value that was read from flash differs from 0xabcd1234.  Also I tried to write data (0xabcd1234) to address 0x01f0 0000 instead of address 0, but it didn't help. Changing CS assert and deassert delays doesn't influence the result...

In contrast to Remote System Upgrade over UART based on Nios II Processor with EPCQ example, where we need 128kbytes of onchip_mem for Nios2 program, Generic Flash Access reference design needs only 40kbytes, but it doesn't work in my case...

 

From Nios II Console:

------------------------------------------

Flash Device: Intel FPGA EPCQ256

Device ID: 1019ba20

Status reg: 000000ff

Sector protection failed due to error in setting status register

Status Register: 00000064

Check datasheet to find out

-----------------------------------------

 

redefine mask_sr2 as 0x64 and start the program:

 

-----------------------------------------------

Flash Device: Intel FPGA EPCQ256

Device ID: 1019ba20

Status reg: 000000ff

All sectors in this configuration device is not protected

Now performing sector protection...

All sectors in this configuration device is now successfully protected

Trying to erase sector 0...

Erase Error as erase is not allow during sector is protected!

Now perform sector unprotect...

Sector unprotect successfully!

Reading data at address 0...

Memory content at address 0: ffffffff

Address 0 not containing data...

Writing data to address 0...

Read back data from address 0...

Current memory in address 0: 8020aa4

Something is wrong...

----------------------------------------------

 

Change mask_sr2 to original value 0x83 and run again:

 

-----------------------------------------------

.....

Read back data from address 0...

Current memory in address 0: 8020aa4

Something is wrong...

-----------------------------------------------

 

Sergey81
Novice
285 Views

Finaly GSFI IP works. Probaly the problem was related to FPGA routing delays. I used pll to get clk for GSFI, but I didn't assign timing constraints. Then I got rid of pll and program worked.

In previous post I wrote that Generic Flash Access reference design needs only 40kbytes, but if we add a remote update IP and make changes in NiosII program to organize a menu and to load an App1 Image or software file (in Remote System Upgrade over UART based on Nios II Processor with EPCQ-example scanf function is used for this) the program size will need 128 kbytes of onchip_mem.

I tried execute-in-place method (in this case we can reduce onchip_mem since text section of the program isn't loading into onchip_mem - see AN-736 Nios II Processor Booting From Altera Serial Flash (EPCQ), but scanf function doesn't work normally. Now I'm trying to read bytes from UART using IORD_ALTERA_AVALON_UART_STATUS and IORD_ALTERA_AVALON_UART_RXDATA (Nios II booting method with boot copier which copies all section including .text into onchip_mem) - without HAL API and scanf function, but it works strange. Maybe I have to disable altera_avalon_uart_driver in BSP settings...

Sergey81
Novice
240 Views

As for Remote System Upgrade over UART based on Nios II Processor with EPCQ example, I found out that we can use small driver version for altera_avalon_uart_driver (BSP Editor settings). In this case printf operator is available (that's convinient to organize menu). And we can use IORD commands instead of scanf. So, the size of program can be significantly reduced and we only need 32kbytes of onchip_mem (turn on Small C and Reduced Device Drivers options in BSP properties to reduce the size of the program). Also we must take into account that Remote Terminal from Intel doesn't transmit bytes from .rpd-file directly. It transmits ASCII-codes of bytes. For example, FF byte will be transmitted as 0x66, 0x66 (2 bytes). 0x66 is an ASCII-code for F. After 8bytes (4 bytes each expressed as 2 ASCII-codes) Remote Terminal transmits two bytes 0x0A (Enter). This format is probably caused by using scanf-command into example. So  it seems it's a good idea to write a simple program in C or other language to transmit file from PC to Nios2 without transformation original bytes into couples of bytes and using 0x0A,0x0A -separators (process of updating will take 2.5 times less time).

Reply