Bug in hwlibs alt_qspi.c driver ?

[PHJ]

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 !

[Fawaz_Al-Jubori]

Thank you for your information. I will send these details to our internal team for their investigation. Thanks

[PHJ]

​Hi -

Is there any update available from the internal team investigation yet ?

Thanks !

Paul

[mbzeo]

I have the same problem and I am using hwlib version 18.1

[PHJ]

@FJumaah​  - is there any update available from the internal team investigation yet ?

Thanks !

Paul

[Fawaz_Al-Jubori]

Hello sir, I filed a bug issue and waiting for our internal team confirmation. Once I get a reply, I will let you know. Thanks

[Fawaz_Al-Jubori]

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

[PHJ]

​Hi  @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

[MCOUNSELL]

Hi all,

I've seen what I think seem to be bugs also.

1. reads return data from qspi address + 1 .... odd
2. 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]

​Hi @FJumaah​ -

Is there any further update on this ?

The last suggestion from a month ago did not resolve what I am seeing ?

Has anyone at Intel managed to reproduce this problem ?

Thanks,

Paul

[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 · Accepted solution]

​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.