Forum Discussion
Occasional ContributorBug in hwlibs alt_qspi.c driver ?
I've run into a problem trying to use the hwlibs alt_qspi.c flash driver on the Arria 10 SoC DevKit. This is the version that came with the SoCFPGA-GettingStarted-A10-GCC example:
* $Id: //acds/rel/16.1/embedded/ip/hps/altera_hps/hwlib/src/hwmgr/alt_qspi.c#2 $
It works OK for me until I enable the ARM caches.
My code is running from DDR and I've enabled caching to the DDR.
I've reduced the problem to the following environment:
- Erase sector A
- Erase sector B
- Erase sector C
- Write data to sector A
- Write data to sector B
- Write data to sector C
- Erase sector A
- Erase sector B
When I check the data in the three sectors I see that sector C seems to have been erased, yet sector A & B have not !
This test works OK with the caches disabled.
There appears to be some race condition in the alt_qspi_erase_helper routine. If I add some delay between the call to alt_qspi_stig_addr_cmd and the call to the wait func, then the test works OK. I cannot find a reason why such a delay would be needed.
I've attached a DS-5 project that shows this fault. The simple test code for this is in FlashTest.c. The alt_qspi.c code contains some #if0 code that allows the test to work when included.
Has anyone else seen problems like this ?
Can someone from Intel investigate please ?
Thanks !
I have pushed this issue thru our supplier to Intel to get an answer.
This is their response:
I have reproduced the issue and I believe I have found the root cause. Please poll for QSPI controller register cfg field idle until it is equal to 1 at the end of the function alt_qspi_stig_cmd_helper() and it will fix the issue.I have patched alt_qspi.c with this change and it does fix the issue we were seeing.
11 Replies
FawazJ_AlteraFrequent Contributor
Thank you for your information. I will send these details to our internal team for their investigation. Thanks- FawazJ_AlteraHello sir, I filed a bug issue and waiting for our internal team confirmation. Once I get a reply, I will let you know. Thanks
- FawazJ_Altera
Hello sir,
This behavior might be due to bufferable transaction.
Can you add isb() or dsb() equivalent function within HWLib after function call alt_qspi_stig_addr_cmd?
Thanks
PHJHi @FJumaah -
This has not made a difference - the test still fails.
I added an __asm("DSB") instruction after the call to alt_qspi_stig_addr_cmd. I also tried __asm("ISB"), __asm("DMB") and a combination of the three.
I wasn't sure which transaction was bufferable, and so also tried adding the same instructions around the register writes in alt_qspi_sitg_addr_cmd() and alt_qspi_sitg_cmd_helper(). The test still failed for all these cases.
Did you manage to reproduce the problem there? I have realised that the project I sent referenced the incorrect linker command file, but if you update the project to use the arria10-dk-ram-hosted.ld file that was included in what I sent then you should be able to see the same problem when run on an Arria10 dev board with the QSPI flash present.
Best Regards,
Paul
MCOUNSELLHi all,
I've seen what I think seem to be bugs also.
- reads return data from qspi address + 1 .... odd
- sometimes gets stuck in alt_qspi_write_helper() and just busy waits for something ... i think it is related to the indirect fill level.... it is as if cannot write any more so it just busy waits for ever... is this a bug or h/w issue?
I'm using the Altera dev kit hardware which I assume is working OK...
- PHJ
I have repeated this same issue with the 18.0 version of hwlibs.
I have attached the DS-5 project files used for this....
- PHJ
I have pushed this issue thru our supplier to Intel to get an answer.
This is their response:
I have reproduced the issue and I believe I have found the root cause. Please poll for QSPI controller register cfg field idle until it is equal to 1 at the end of the function alt_qspi_stig_cmd_helper() and it will fix the issue.I have patched alt_qspi.c with this change and it does fix the issue we were seeing.
