QSPI signals for nRF7002

[gr-grinn]

Hi!

I'm trying to portnRF7002  QSPI bus driver for one of the NXP MCUs. Communication with nRF7002 under Zephyr is already established and everything works as expected.

Driver port is nearly finished, but I have issues with making sure that QSPI transfer for PP4 and READ4 meets nRF7002 requirements.

From the datasheet (nRF7002_PS_v1.1.pdf):

1. Figure 9 shows, that during 4-dummy bits IO3 is high. Is this required, or just to show that IO lines state does not matter?
2. Based on the figure 11 I assume, that the mentioned 4th byte boundary is about Data out bytes?
3. If the 4th byte condition is not met, is the whole operation not valid or is only last partial 32-bit part dropped?

QSPI peripheral that is available seems to be somewhat limited regarding cycles not equal to 8 clock cycle. I am looking for some workaround, based on nRF7002 tolerance for not perfect QSPI transactions.

[Simonr]

Hi

Unfortunately the documentation on this is scarce, but we have this Github repo showcasing bare metal driver for the nRF70 that can do scanning and radio-test and should work as starting point.

Best regards,

Simon

[gr-grinn]

Hi,

thanks. I have already made it work based on QSPI support in Zephyr. Write command workaround is working correctly and read command issue does not need solving, as there seems to be 8 dummy bits instead of 4 showed in the Figure 9.

And I agree about scarce documentation, it does not help with different platforms integration.

With regards

[Simonr]

We are currently working on improving this documentation, however I don't have an estimate for a release yet. 

As for the case at hand, I'm currently waiting for a reply from a colleague that has been doing this themselves. I'll let you know when I hear back from them.

Best regards,

Simon

[Simonr]

Hi

1. The dummy bit should not matter.

2. Regading question 2 about figure 11. This 4 byte limitation goes for QSPI transmission in general as all payloads need to be a multiple of four bytes. For PP4IO, you have one command byte (8 clock cycles) and the 24 bit address (6 clock cycles), then I.E. a 4 byte payload (8 clock cycles on QSPI). 

3. I think only the last 32-bit packet will be erroneous, but please note that if the buffers aren't word aligned, this might cause data shifts on subsequent transmissions, so I strongly recommend you make sure all data is word aligned to a multiple of 4 bytes to avoid this.

Best regards,

Simon