• State
  • Locked Locked
  • Replies 4 replies
  • Subscribers 97 subscribers
  • Views 331 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.

OMAP3530 DSP Access to SOC Peripherals

SamL
Prodigy 40 points
Other Parts Discussed in Thread: OMAP3530, CODECOMPOSER

I am interested in using the DSP within the OMAP3530 to read and write to a MMC device.  There is a note on the bottom of page 188 on the OMAP3530  TRM (spruf98p) which states "IVA2.2 subsystem (DSP) can’t access SoC peripherals".  This suggests that the DSP cannot access the MMC.  Is this statement correct?

By observation, when JTAG-debugging the DSP I can read/write SOC peripheral memory-mapped registers.  Also there is a thread on this forum ("How to access external peripheral from C64x+ DSP") which discusses DSP access to a memory-mapped peripheral (FPGA on CS4 in this case).  Is this access somehow different than accessing the MMC?

The short question would be: can I access a device on MMC from the DSP?

Thanks in advance for your comments.

Sam.

  • 0
    TI__Expert 4745 points

    Sami,

    The DSP won't "address" the MMC directly...it will be able to retrieve blocks of data via a driver that can move data with help of DMA.

    I believe that driver would normally reside on the ARM.

    What did you have in mind as the role for the SD/MMC? 

     

  • 0 in reply to DaveB123
    Prodigy 40 points

    Dave,

    Can you clarify what you mean when you say "the DSP won't 'address' the MMC directly."  Do you mean that the DSP can't access the MMC register set?  Or do you mean that the interaction isn't effective because e.g. the DSP cannot set up DMA transfers with the MMC peripheral without the ARM?  I am confused by this assertion because using CodeComposer Studio in a JTAG session with the DSP core, I can cause the DSP to examine SOC peripheral registers (including the MMC). 

    As for the application, I am moving bi-directional data through the OMAP using an MMC device on one side and a memory-mapped (PLD) device on the other.  I am exploring peripheral connectivity with the cores so that I understand my options for high speed data movement and processing.

    Many thanks for your response and continued dialog.

    Sam.

     

  • 0 in reply to SamL
    TI__Expert 4745 points

    Sam,

    thanks for the clarification.  What I wanted to make sure you understood was that the Address and Data bus on the embedded DSP core would not "execute or address immediate data" in the MMC as if it was local to the DSP memory bus.  I'm not 100% sure the MMC registers are available to the DSP memory reach, but pretty sure they are for the ARM.

    It sounds like you ultimately want to understand the path from SD/MMC to the PLD via DMA.d

    On what external bus would your PLD reside? (GPMC?) 

    SD/MMC <-> DMA <-> sDMA <-> PLD (at GPMC)

    Or, is there some addtional processing you need to do in the DSP along the way?

  • 0 in reply to DaveB123
    Prodigy 40 points

    Dave,

    I have a little bit more clarity on the design from in-house discussions.   As I now understand, the ARM will actually interface with the MMC device.  There is significant data manipulation to be done before passing the data to (and from) the PLD (which is indeed on the GPMC).  The goal was to involve the DSP as much as possible to maximize performance.   We will be running Linux on the ARM and DSP Link to the DSP. 

    At this point, I need to understand how to implement the fastest transfer of data from the DSP to the GPMC.  I wouldn't mind suggestions, but I need to go back to the TRM and do some reading to avoid asking the broad question: "How do I do that?" 

    I'll come back with a specific question when I have one.

    Thanks,

    Sam.