• State Resolved
  • Locked Locked
  • Replies 10 replies
  • Subscribers 31 subscribers
  • Views 194 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.

AM2434: OSPI Nor Flash: Using both DAC for XIP and INDAC for filesystem

Stefan Schlee
Prodigy 185 points

Part Number: AM2434

On AM243x, I want to use OSPI flash in two modes at the same time:

  • DAC mode for XIP execution
  • Indirect read/write for filesystem access

The MCU+ SDK OSPI docs describe both direct (memory-mapped) and indirect modes, and the driver has separate APIs for them.

However, the current driver appears to disable DAC mode temporarily for each indirect access.
My concern is that this would cause an abort if XIP code is fetched during the indirect transaction.

My understanding from the TRM is that DAC can remain enabled while indirect accesses are triggered via the indirect access trigger region, provided that region is outside the XIP address window.

So:
Is DAC deactivation during indirect access truly required by the hardware, or is it only how the SDK driver is currently implemented?
If the hardware allows both concurrently, is it valid to keep DAC enabled and place the indirect trigger region away from the XIP area?

Thank you very much on any help on this topic!
Best Regards, Stefan

  • 0
    TI__Guru 58755 points

    Hi Stefan,

    Highly recommended to have both the accesses separately. Any reason why concurrent access is required, and how are you doing so? I would appreciate if you can explain a bit of your system/design around FLASH/OSPI Controller.

    Regards,

    Vaibhav

  • 0 in reply to Vaibhav Kumar
    Prodigy 185 points

    Hi Vaibhav,
    we are currently designing a multitasking application:
    XIP should be used to place large, non-time-critical code in flash memory.
    Indirect access should be used to access a littlefs-based filesystem located on the same flash.
    Implementing a semaphore-based mechanism to coordinate filesystem access with code executing via XIP would be very difficult and would introduce tight coupling across the entire codebase.
    Preventing concurrent indirect accesses can be handled quite easily in a common flash driver or directly within the filesystem.
    However, I do not see how this could be achieved for direct XIP accesses.
    As far as I understand the TRM section covering the DAC and INDAC OSPI controllers, the hardware itself should be able to handle concurrent accesses by inserting wait states.
    The MCU SDK even states that concurrent DAC/XIP accesses for multiple CPU cores is no problem, as the DAC inserts wait states.
    However, I have not tested this yet for the DAC/INDAC combination and would be very interested to hear your thoughts on this.
    Best regards,
    Stefan

  • 0 in reply to Stefan Schlee
    TI__Guru 58755 points

    Hi Stefan,

    Stefan Schlee said:
    However, I have not tested this yet for the DAC/INDAC combination and would be very interested to hear your thoughts on this.

    So when doing simultaneous access with DAC and INDAC use case clubbed together, might result in undefined behaviour.

    When the DAC is enabled, the contents of the flash gets mapped to the SOC address starting 0x60000000 and then we issue DAC reads. To summarize, the OSPI is in DAC state and thereby accessing the flash in DAC state.

    But if you club it with INDAC mode, even though the address for INDAC is different compared to DAC, this would lead to undefined behaviour. The OSPI Controller can either be in a DAC or an INDAC state, at any given moment but not act like both.

    Let me know if this clarifies a little bit more on the DAC vs INDAC front.

    Regards,

    Vaibhav

  • 0 in reply to Vaibhav Kumar
    Prodigy 185 points
    Vaibhav Kumar said:
    The OSPI Controller can either be in a DAC or an INDAC state, at any given moment but not act like both.

    My understanding of the TRM disagrees with this point.

    Obviously, the OSPI can only service a DAC or INDAC request at any given moment, but it seems like both DAC/INDAC interfaces to the CPU can be open simultaneously. Wether the DAC or INDAC controller is used, is decided by the INDAC memory address trigger region.

    Here are some related snippets from the TRM:

    12.3.2.4.8.3 Access Forwarding

    For legal accesses, the data interface will forward all accesses to one of two access controllers - the direct access and the indirect access controllers. Assuming DAC has been enabled via the OSPI_CONFIG_REG[7] ENB_DIR_ACC_CTRL_FLD bit, then by default all accesses will be forwarded to this controller. Before any accesses can be forwarded to INDAC, it must first be configured by software. This process is fully explained in Section 12.3.2.4.10, Indirect Controller (INDAC). If DAC is disabled, any incoming access that cannot be SPRUIM2H – MAY 2020 – REVISED OCTOBER 2023 Submit Document Feedback 8399 AM64x /AM243x Processors Silicon Revision 2.0 Texas Instruments Families of Products Copyright © 2023 Texas Instruments Incorporated Peripherals www.ti.com forwarded to INDAC will be completed immediately with an error. If DAC is enabled, the same access will be forwarded and serviced by DAC.

    There even seems to be a fixed priority scheme for servicing concurrent accesses (i just found that section): 

    12.3.2.4.12 OSPI Arbitration Between Direct / Indirect Access Controller and STIG

    When multiple controllers are active simultaneously, a simple fixed-priority arbitration scheme is used to arbitrate between each interface and access the external FLASH. The fixed priority is defined as follows, highest priority first. • The Indirect Access Write • The Direct Access Write • The STIG • The Direct Access Read • The Indirect Access Read

    I think the latter section answers my original question: it should be possible in theory.

    However, the current SDK driver does not support this behaviour at this point.

    Best regards,
    Stefan

  • 0 in reply to Stefan Schlee
    TI__Guru 58755 points

    Hi Stefan,

    In the INDAC implementation the very first thing which is performed in the software driver is disabling DAC mode.

    Regards,

    Vaibhav

  • 0 in reply to Vaibhav Kumar
    Prodigy 185 points

    Hi Vaibhav,

    yes i know, but i think this is not required by the OSPI peripheral.

    My idea is to modify the driver to leave the DAC activated, thus allowing concurrent accesses to DAC/INDAC.

    Regards,
    Stefan

  • 0 in reply to Stefan Schlee
    TI__Guru 58755 points
    Stefan Schlee said:
    My idea is to modify the driver to leave the DAC activated, thus allowing concurrent accesses to DAC/INDAC.

    Let me check this internally.

  • 0 in reply to Stefan Schlee
    TI__Guru 58755 points

    Hi Stefan,

    Stefan Schlee said:

    I think the latter section answers my original question: it should be possible in theory.

    However, the current SDK driver does not support this behaviour at this point.

    The current driver is written in Polling mode.

    I have asked this query up with the SW team to confirm.

    I will update you once I have more findings.

    Thanks,

    Vaibhav

  • +1 in reply to Vaibhav Kumar
    TI__Guru 58755 points

    Hi Stefan,

    I have confirmed that it works.

    So the TRM spec says multiple Controllers, and I assumed the Controllers here to be the OSPI Controller, but it is the DAC and INDAC controller being referenced.

    I have tested as well in the SDK, and it works just fine.

    So basically I have the DAC enabled all the time, and when I remove the logic of Disabling DAC from the OSPI_writeIndirect API, it works.

    Not that we are going to change this in the SDK going forward, but yes its possible and it matches with what the TRM is stating.

    Thanks,

    Vaibhav

  • +1 in reply to Vaibhav Kumar
    Prodigy 185 points

    Hi Vaibhav,

    Thank you for looking into this issue!

    I have also tried a simple test leaving the DAC enabled, and can confirm your results.

    However, i then stumbled over a limitation of our nor flash chip, which is not able to perform valid reads during a write/erase operation.
    So in the end we still have to lock out XIP access during flash writes/erases.

    Nevertheless i think this behaviour should be changed in the SDK, because there are flash chips which allow read-while-write access.

    Furthermore, then the flash read API could use OSPI_readIndirect() instead of OSPI_readDirect(), which seems to be rather slow, if the driver and flash chip are not configured for XIP mode.

    Best Regards,
    Stefan