We are seeing few errors flashing the QSPI NOR Flash connected to HPS with Command shell as per the link: https://rocketboards.org/foswiki/Documentation/A10Gsrd161QspiBoot#Programming_QSPI
Below are the errors occurred:
Sector Erase Quad SPI flash at 0x060A0000
Program Quad SPI flash ...
Verify Quad SPI flash ...
Error: Fail to match data at flash address 0x000003FC with file address 0x000003FC. Found 0x34 but expect 0x00
Error: Quartus Prime Programmer was unsuccessful. 0 errors, 0 warnings
Error: Peak virtual memory: 4269 megabytes
Error: Processing ended: Sun Sep 09 03:29:56 2018
Error: Elapsed time: 04:30:47
Error: Total CPU time (on all processors): 00:46:45
We are using 1Gb QSPI with minimal file systems for arria10 in our case.
Has anyone come across these errors, kindly help us resolve this issue.
Thanks & Regards,
Is it on a development kit or a custom PCB? If custom, which flash are you using?
On our custom PCB we have the same problem when using a Micron MT25QL512ABB8E12-0SIT but it works fine with a Cypress S25FL512SAGBHIC1.
I didn't investigate that much because both the flash are working with our own software, that uses a lower frequency than the quartus_hps command line tool. It could be signal integrity problems but we were careful when routing the board, and adding 33 ohm resistors on the lines didn't change anything.
I haven't found a way to reduce the clock frequency quartus_hps uses either, and if anyone knows I'd be interested.
Its on the custom PCB. We are using the Micron's 1GB flash part(MT25QU01GBBB8E12-0SIT) with Arria10 SOC. We do have a series 33E resistors on board for the flash interface signals.
If anyone can help us a way to understand & resolve this error, it would be grateful.
Thanks & Regards,
Then you could have the same problem than me. I don't know if quartus_hps has an option to reduce the SPI frequency, but if it does it is not documented so only Intel can answer that question.
My current solution is to upload the preloader and our flashing software (based on Redboot) through JTAG first and then use our software to write to the flash.
You could also try a Cypress/Spansion chip but it's not that easy to change a BGA chip on a PCB without specialized equipment.
Were any of you able to find a solution to this?
We are also developing a custom board and are having the exact same issue, at the exact same address 0x000003fc when verifying flash programming.
Using a Micron - MT25QL02GCBB8E12-0SIT with a Cyclone V SoC 5CSEMA5F31I7N.