QSPI STRANGE BEHAVIOR WHEN AUTOPOLLING

[JCuna.1]

I am trying to autopoll wip and wel bit from status register (0x05) in a flash memory when I perfrom a erase process.

The first autopolling operation is correctly, however, the second time that qspi try to autpoll the bits, this does not release CS, and the data is not readed correctly. I am using HAL_QSPI and inmediatlly after perfrom the aupolling hal line, it finish, but the peripheral continue polling the bits forever.

[Tesla DeLorean]

Weird for sure... pretty sure it should work with 1, you'd use 2 for a dual configuration, where you do want both die to complete, and the erase/write are self-timed, so one device is usually done ahead of the other. Full erase of parts can take minutes, definitely hundreds of seconds.

@Imen DAHMEN​  @Amel NASRI​  @STOne-32​  please have someone on the QUADSPI / OCTOSPI validation team look this over, thanks..

[JCuna.1]

Testing in 1_line (normal spi) mode, the autopolling works perfectly, CS is releasing after each poll.

[JCuna.1]

W25Q32JV-DTR indicate:

[Tesla DeLorean]

Yeah, so 60 seconds for a timeout is reasonable here, been working with the 1 and 2 Gb parts with multiple 512Kbit die inside.

[JCuna.1]

It is not possible custom format frame for quad spi in autopolling mode

https://www.st.com/content/ccc/resource/technical/document/application_note/group0/b0/7e/46/a8/5e/c1/48/01/DM00227538/files/DM00227538.pdf/jcr:content/translations/en.DM00227538.pdf

[Tesla DeLorean]

@ChahinezC​ marking for review, I think this was the primary thread, although there may be additional ones within this immediate time period.

Thanks, -Clive

[Tesla DeLorean]

One of my conclusions at the time was that the bus is left active via the timeout path, and actually needs to be aborted. I think this should be handled within the functions timeout path directly, as NONE of the example codes look to be handling anything related, and the failure will just cascade from there.

There are of couple of related threads.