QSPI signals for nRF7002

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.

Parents
  • 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

Reply
  • 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

Children
No Data
Related