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.

AM2434: Maximum clock frequency for OSPI Flash

Part Number: AM2434
Other Parts Discussed in Thread: SYSCONFIG

I checked the example "OSPI Flash IO" in the MCU+ SDK to reference the clock frequency to OSPI Flash.

software-dl.ti.com/.../EXAMPLES_DRIVERS_OSPI_FLASH_IO.html

In the example, Flash and OSPI are configured by SysConfig and the OSPI clock seems to be set at 133 MHz / 4 = 33 MHz.

The S28HS512T supports up to 200 MHz clock in the datasheet.

AM243x supports up to 166 MHz (6.02 nsec) clock in DDR mode in the datasheet.

Are clock frequencies above 33 MHz validated for the TMDS243GPEVM?

Is there a detailed document for configuring Flash and OSPI by SysConfig?

Best regards,

Daisuke

  • Hi,

    In the example, Flash and OSPI are configured by SysConfig and the OSPI clock seems to be set at 133 MHz / 4 = 33 MHz.

    I checked by running "OSPI Flash IO". When the "Input Clock Divider" is 4 (default), all tests pass, but when it is 2, no tests pass (nothing is output on the console).

    Is it correct to reduce the value of "Input Clock Divider" for faster OSPI clock?

    Are clock frequencies above 33 MHz validated for the TMDS243GPEVM?

    Is there a detailed document for configuring Flash and OSPI by SysConfig?

    Best regards,

    Daisuke

  • Hi Daisuke-san,

    The SDK examples has "PHY Mode" as enabled. If PHY Mode is enabled the "internal divider values" set, are ignored.
    So the example is still working on 200MHz.

    Best Regards,
    Aakash

  • Hi Aakash-san,

    Thank you for you reply.

    I checked the OSCI clock frequency while running the OSPI Flash IO example. It seems to be 133MHz during burst access and 33MHz otherwise, is that correct?

    Best regards,

    Daisuke

  • Hi Daisuke-san,

    We keep PHY disabled during writes so maybe the clock goes 33MHz at that time.

    Let me get more information on this.

    Best Regards,
    Aakash

  • Hi Aakash-san,

    Thank you for you reply.

    I have confirmed that only during Read (in Flash_norOspiRead()), OSPI clock is driven at 133 MHz and the PHY mode is enabled.

    I am still a little confused about the OSPI clock settings.

    In "Figure 12-1541. Read Data Capture Logic" on the TRM, the clock (OSPI_OCLK) via the divider seems to be used for the PHY module.

    To ignore the divider in PHY mode, need to set it to divide by 1?

    Is the divider value set by the MSTR_BAUD_DIV_FLD field in the OSPI_CONFIG_REG register?

    Best regards,

    Daisuke

  • Hi Aakash-san,

    Thank you for your support. Our customer is waiting for your answer.

    Please give me an answer as soon as possible. Your prompt reply would be appreciated.

    Best regards,

    Daisuke

  • Hi Daisuke,

    To answer your questions, I'll lay down some facts about the OSPI controller:



    1. If the PHY is not enabled, maximum output clock speed the OSPI controller can safely operate at is 50MHz. How you achieve this using the input clock and divider is upto you. It is recommended to keep the divider value as multiples of 4 for stability. So one recommended way to achieve this is 200 MHz input clock and divider as 4. You can set these in the SysConfig of the example.

    2. If the PHY is disabled, the divider value is ignored. So output clock = input clock.

    3. It is recommended to use the PHY mode only using reads. In all the other times, it is best to restrain from using the PHY because there is no real value. Other than read, the only operations are write and erase. Their performance is not entirely dependent on the data we sent. Time taken for both erase and write operations highly depend on the flash. After writing each page (generally 256 bytes), the OSPI controller will have to wait for a flash-specific time period till it can write the next page. So even if you could enable the PHY during writes in theory, the stall time after every page write is not going to reduce. If we take the case of erase, there is not much data going from OSPI to the flash anyway. The time taken to erase a particular sector/block is again dependent on the flash.

    On top of this, for STIG operations or for sending commands to the flash other than read, write or erase, PHY is not recommended. So it was a design choice to use the PHY only for reads. But PHY with writes is tested (at least experimentally). So you could in theory enable PHY during a page write and disable it write after that.

    If there is a need to have PHY enabled for operations other than read, there are ways to do it like I mentioned above. But without PHY, the maximum safe speed is 50 MHz. So setting the divider value to 1 or 2 which would result in output clock > 50 MHz would not be a good idea.


    So to help you better, let me know what exact usecase the customer is looking for here.

    Regards,
    Anand M

  • Hi Anand M-san,

    Thank you for your detailed response.

    Our customer was considering to select a clocking topology supported in PHY mode.

    Each of the clocking topologies has limitations.

    e2e.ti.com/.../am2434-clocking-topologies-for-the-receive-data-capture-clock-in-phy-mode

    e2e.ti.com/.../faq-ospi-faq-for-sitara-jacinto-devices

    The DQS clocking topology should be used for High-speed (>50 MHz) operation as TAP mode cannot be used with External Board Loopback.

    Best regards,

    Daisuke

  • Hi Anand M-san,

    I have an additional question.

    2. If the PHY is disabled, the divider value is ignored. So output clock = input clock.

    Is the above incorrect and the below correct?

    2. If the PHY is enabled, the divider value is ignored. So output clock = input clock.

    Best regards,

    Daisuke

  • Daisuke-san,

    Apologies. My mistake. It was a typo. You're right. If the PHY is enabled, then the divider value is ignored. So output clock = input clock in that case. And yes, the customer can go forward with DQS clocking. Let me know if you have any more queries.

    Regards,
    Anand M

  • Hi Anand M-san,

    Thank you for you reply.

    Best regards,

    Daisuke