• State
  • Locked Locked
  • Replies 8 replies
  • Subscribers 99 subscribers
  • Views 556 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

AM4376: QSPI CLK behaving discontinuously, in bursts, during word transfer

Peiman
Prodigy 90 points
Part Number: AM4376


We are using QSPI on the AM4376 to communicated with an FPGA. Although we can communicate to the device, we've found the throughput to be to be unexpectedly low. When looking at signals on a scope, found that QSPI clock was not continuous, but in bursts of two during a single word transfer :

In the above capture, CH1 is CS, CH2 is SCLK, CH3,4 unconnected. We are using 8 bits/word and CLK MODE 3, 10MHz clock.

Are there any settings or combination of settings that can cause SCLK to behave discontinuously, as above?

  • 0
    TI__Guru**** 198079 points

    Hello Peiman

    Thank you for the query.

    Can you help me understand the expected throughput vs the throughput you are seeing. Please verify the configuration of the interface.

    Please share the development environment you are using.

    Please refer the below section 

    Chapter 27, QSPI

    This chapter describes the QSPI of the device.

    Regards,

    Sreenivasa

  • 0 in reply to Kallikuppa Sreenivasa
    Prodigy 90 points

    The throughput is a symptom which revealed the discontinuous QSPI clock, shown in original post. The main concern is the discontinuous CLK behavior, which will in turn affect throughput. 

    This is seen during a Linux QSPI transaction and also on baremetal. We are using 8 bits/word and CLK MODE 3, 10MHz clock. We can successfully communicate to the QSPI device, however the QSPI clock comes in bursts of two.

    Are there any configuration items that can lead to this behavior? 

  • 0 in reply to Peiman
    TI__Guru**** 198079 points

    Hello Peiman

    Thank you.

    Could you please share the OSPI configuration and allow review the below register 

    27.4.1.10 QSPI_CMD_REG Register (offset = 48h) [reset = 0h]

    Regards,

    Sreenivasa

  • 0 in reply to Kallikuppa Sreenivasa
    Prodigy 90 points

    Hello Sreenivasa,

    These are the register contents after a transaction:

    Sorry if hard to read. QSPI_CMD_REG value = 0x003F0FFF

    WLEN = 0x7

    Thanks,

    Peiman

     

  • 0 in reply to Peiman
    TI__Guru**** 198079 points

    Hello Peiman,

    Thank you.

    Could you please provide a summary of the hardware interface that you are using.

    Regards,

    Sreenivasa

  • 0 in reply to Kallikuppa Sreenivasa
    Prodigy 90 points

    Hi Sreenivasa,

    We are using the QSPI interface connected to an FPGA. Configuration uses, 1 wire transmit, 4 wire receive. We have tried programming QSPI clock to 10MHz and 20MHz. The clock period (measured on scope) corresponds to the programmed rate, but the clock idle time remains (seen above).

    Thanks,

    Peiman

  • 0 in reply to Peiman
    TI__Guru**** 198079 points

    Hello Peiman,

    Thank you for the inputs.

    Is the FPGA always a slave?

    1 wire transmit, 4 wire receive.

    Please elaborate the configuration.

    Peiman said:
    but the clock idle time remains

    Could you measure the idle time.

    Did you say it is same irrespective of the clock speed?

    Can you please capture the data signals with respect to the clock.

    Regards,

    Sreenivasa

  • 0 in reply to Kallikuppa Sreenivasa
    TI__Guru* 88550 points

    Peiman, i think you have to determine how the Linux driver is sending data to the QSPI module and triggering the transmission.  There are four 32-bit data registers, so i think if you fill these up and then trigger the transmission, you should see more bursting on the interface.  Sec 27.3.1.5 explains the behavior.  I think what is happening is that Linux is taking a long time to retrigger the next transmission.  It's possible the Linux driver is just assuming single access 8-bit data and not attempting to burst any data.  

    Regards,

    James