- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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=1U-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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
You can erase whole flash from command line:
quartus_hps -c 1 -o E- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
--- 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)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
--- 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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Use the flash_erase all the partition , and then reflash new content again.

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page