New Contributor
New ContributorI'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...
-----------------------------------------------
New ContributorFinaly 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...
New ContributorAs 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).
