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.

AM5726: PRU access to memory

Part Number: AM5726
Other Parts Discussed in Thread: AM4376

I need to access a memory mapped device through PRU. The main CPU also needs to access the same memory area, but not identical adresses. Will this be possible at all? Will the PRU wait when the memory is busy? It is a slow memory, 1 access needs about 100ns, so either core would have to wait while the other has access to the memory.

  • Is this an external device? Where is it connected? What software are you running on the ARM?
  • we use Linux. The device is a dual-ported ram, some adresses are decoded seperatly to access LED or switch on some external port.
  • Hello Annette,

    How is the device connected to the AM5726 memory? (e.g., does the system access it through the General-Purpose Memory Controller?)

    Regards,
    Nick
  • Hello Nick,

    yes, it is General purpose memory controller (GPMC) asyncron, none-multiplexed 8-Bit Mode

    Regards, Annette

  • Hello Annette,

    Do you have a block diagram, or a schematic, or some other visual for 1) how the system is connected and 2) how the ARM and PRU cores are intended to communicate with the dual-ported RAM? This is not a typical use case for the AM57xx family or for exchanging data with the PRU core, so I want to make sure I understand what your system is doing.

    Regards,

    Nick

  • Hello Annette,
    1) Which processor are you using? AM5726, AM4376, something else?
    2) What functions do you want the PRU core to perform, and which functions do you want the ARM core to perform? (please include why each core is accessing the DPRAM)

    Regards,
    Nick
  • Hello Nick,

    we use now AM4376, and for a future board probably AM5726. The ARM core will access the DPRAM and SRAM. The PRU should also access the DPRAM memory area. Some adresses are decoded seperatly to switch on/off some signals. These adresse will then be just used from PRU. It is now all done by the ARM core.

    Regards, Annette

  • Hello Annette,

    The PRU can access the full memory space through its OCP port by setting the PRU_ICSS_CFG_PMAO register. That means it can access the GPMC memory space 0x0000_0000 - 0x1FF_FFFF. The GPMC will arbitrate access between the ARM and PRU cores.

    The PRU memory accesses through the GPMC will not be deterministic. The best-case AM437x read latency for GPMC latency listed in the wiki probably applies to accesses to the GPMC configuration registers (0x5000_0000 - 0x50FF_FFFF) rather than the GPMC external memory, so I don't have a best case read latency estimate for you. I am unsure if the GPMC would prefer one core over the other, or what other system elements could add to latency.

    An alternative setup is continue to let the ARM core conduct all accesses to external memory, and then use local ICSS resources to transmit data between the ARM and the PRU cores. There may be other good setups based on your design's needs.

    Regards, 

    Nick

  • Hi Nick,

    please verify if that information is correct. To my mind the GPMC is an external memory interface and does not sit between PRU and ARM cores. Instead once the flag is set PRU can access the global SoC address space to the full extent. Not sure where you found that info about GPMC.

    There is an internal bus that adds some latency but it is usually not an issue. 

    Seems I got the sentence about arbritration wrong here. Looking at the block diagram further up I can see that GPMC is used for external memory access. As such your comments are corect. Sorry for that.

    Best regards,

     Frank

  • Hello Annette,

    I'm going to mark this resolved. Please let us know if you have any more questions!

    Regards,
    Nick