Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Altera_Forum
Honored Contributor I
2,007 Views

HPS QSPI flash programming

Hi,  

I have an issue with QSPI flash programming by quartus_hps utility. I use EDS 14.1 and run quartus_hps in its command line. I've made custom preloader to boot from QSPI flash and program the memory device. The software placed preloader images 4 times in the very begining of the memory so it seems to be good. But after I repowered my board and saw that preloader had started I can't program flash memory again! The programmer try to read silicon ID but it fails and the whole operation stops. How could I fix this problem? What am I doing wrong? 

Thanks.
0 Kudos
12 Replies
Altera_Forum
Honored Contributor I
221 Views

This is illustration for my problem (from EDS console): 

http://www.alteraforum.com/forum/attachment.php?attachmentid=10101&stc=1  

I'd been advised to erase QSPI flash under u-boot, so I tried. I ran u-boot from SD/MMC, and look what I got: 

http://www.alteraforum.com/forum/attachment.php?attachmentid=10100&stc=1  

U-Boot 2013.01.01 (Feb 03 2015 - 16:11:33) CPU : Altera SOCFPGA Platform BOARD : Altera SOCFPGA Cyclone V Board I2C: ready DRAM: 1 GiB MMC: ALTERA DWMMC: 0 QSPI: QSPI is still busy after poll for 10000 times. SF: Calibration failed (read) *** Warning - spi_flash_probe() failed, using default environment In: serial Out: serial Err: serial Skipped ethaddr assignment due to invalid EMAC address in EEPROM Net: mii0 Warning: failed to set MAC address Hit any key to stop autoboot: 0 SOCFPGA_CYCLONE5# sf erase No SPI flash selected. Please run `sf probe' 

As we can see QSPI controller is unreachable so "sf probe" and consequently "sf erase" can't work. What kind of sorcery is it? I've only once programmed QSPI flash and everything failed! Any ideas, folks?
Altera_Forum
Honored Contributor I
221 Views

You can erase whole flash from command line: 

quartus_hps -c 1 -o E
Altera_Forum
Honored Contributor I
221 Views

I can't, because all quartus_hps commands are based on reading of QSPI flash ID/status, but it fails. For noe I've found out the problem is in QSPI controller, it generates SCLK clock only after HPS reset to read previously loaded data and hangs immediately after this. I view htis clock with oscilloscope and I can see that QSPI controller doesn't work well. I've also tried to reach flash device via Altera QSPI example. But the function of reading silicon ID hangs due to the reason I described. What's wrong with QSPI? How preolader code, loaded to flash can block this core?

Altera_Forum
Honored Contributor I
221 Views

I did build and run QSPI example on my board. It is Altera's DevKit rev D and SoCEDS 14.0.2 

The example boots preloader and application from jtag. 

Can you run any other bare-metl example?
Altera_Forum
Honored Contributor I
221 Views

Yep, I can. I run Altera-SoCFPGA-HardwareLib-QSPI-CV-GNU example as well. The problem arises when execution reaches alt_qspi_enable()->alt_qspi_device_rdid()->alt_qspi_stig_rd_cmd()->alt_qspi_stig_cmd_helper() function (the last one). There is a piece of code: 

do { reg_value = alt_read_word(ALT_QSPI_FLSHCMD_ADDR); if (!(reg_value & ALT_QSPI_FLSHCMD_CMDEXECSTAT_SET_MSK)) { break; } } while (timeout-- || infinite); if (timeout == (uint32_t)-1 && !infinite) { status = ALT_E_TMO; } 

where the execution hangs till timeout. It seems the code fails to read something from flash via QSPI. In the time of polling flash via QSPI there is no activity on the bus, I checked it with oscilloscope.
Altera_Forum
Honored Contributor I
221 Views

I've found a solution. The reason QSPI controller was inaccessible is invalid preloader was generated without any inforamtion about QSPI. I added to Qsys project QSPI flash support by defining it in peripheral pins of HPS component. And then use out-of-date preloader previously made. It is erroneous way to do. And also I load this old preloader to the very begining of flash memory so after its booting QSPI controller is hanged. When I fully rebuilt the preloader with handoff containing information about QSPI I can run Altera example Altera-SoCFPGA-HardwareLib-QSPI-CV-GNU and use QSPI flash erasing to remove invalid preloader. Now flash ID can be read by quartus_hps tool and also I can read/erase/write the device via hwlib functions.  

 

It will be better if Altera add the description of the problem to "Known issues" because it was very simple to hang QSPI and far not to easy to make a solution.
Altera_Forum
Honored Contributor I
221 Views

nice to know. 

 

actualy, all Altera's examples work with GHRD design and i am not working for them. 

 

are you going to test performance, because i am interested how much write takes?
Altera_Forum
Honored Contributor I
221 Views

 

--- Quote Start ---  

are you going to test performance, because i am interested how much write takes?  

--- Quote End ---  

 

Do you mean speed of writing? I think of QSPI to use it for boot purposes. There is NAND flash to use it in work process, but I can't find any Altera examples for NAND. For now I try to learn working with NAND controller. Here is my topic about this, if you are interested in: http://www.alteraforum.com/forum/showthread.php?t=47631 (http://www.alteraforum.com/forum/showthread.php?t=47631)
Altera_Forum
Honored Contributor I
221 Views

hmm... how did you do that..? did you entered Qspi -> HPS -> parameters -> Peripherial Pins and then under the Quad Spi Flash Controller pane you slected "HPS I/O Set 0" ? i do that and it simply adds few pins to my HPS object. did you connected to these pins something or left them unconnected?

Altera_Forum
Honored Contributor I
221 Views

 

--- Quote Start ---  

I've found a solution. The reason QSPI controller was inaccessible is invalid preloader was generated without any inforamtion about QSPI. I added to Qsys project QSPI flash support by defining it in peripheral pins of HPS component. And then use out-of-date preloader previously made. It is erroneous way to do. And also I load this old preloader to the very begining of flash memory so after its booting QSPI controller is hanged. When I fully rebuilt the preloader with handoff containing information about QSPI I can run Altera example Altera-SoCFPGA-HardwareLib-QSPI-CV-GNU and use QSPI flash erasing to remove invalid preloader. Now flash ID can be read by quartus_hps tool and also I can read/erase/write the device via hwlib functions.  

 

It will be better if Altera add the description of the problem to "Known issues" because it was very simple to hang QSPI and far not to easy to make a solution. 

--- Quote End ---  

 

 

Serjjo, I am having the exact same problem. I flashed QSPI with the prebuilt preloader and application from cv_boot_guide and it boots up fine, but now I can't re-flash the QSPI or even erase it. I get "Error: Not able to map flash ID from flash database" when I run quartus_hps. I don't understand your solution. How were you able to erase and re-flash QSPI?
Altera_Forum
Honored Contributor I
221 Views

This is seems like a continuation of another post earlier, I think what he did was erased the whole qspi blocks and reload all the preloader and hello image.

Altera_Forum
Honored Contributor I
221 Views

Use the flash_erase all the partition , and then reflash new content again.

Reply