• State
  • Replies 3 replies
  • Subscribers 32 subscribers
  • Views 71 views
  • Users 0 members are here
Support feedback
Options
Options
Related

AM263P4: Accessing the PRU memory from a core R5F

michele sponchiado
Prodigy 30 points
Part Number: AM263P4
Other Parts Discussed in Thread: OMAP-L137

Hi, dear TI support service!

In an AM263P4 chip (I am still waiting for the Launchpad kit unfortunately), I am currently trying to access the PRU memory PRU0_DMEM_0 from the core R5F 0 to implement a custom queue from the R5F and the PRU core.

ATM, I have defined a custom memory region at address 0x48000000 (this address value is a courtesy of ChatGPT...) in the .syscfg file, so that the linker.cmd file now has this section:

  •     GROUP (NOLOAD) :   {
        PRU_sync : {
        } align(8)
        } > 0x48000000  

And this custom region:

  • CUSTOM_X   : ORIGIN = 0x48000000 , LENGTH = 0x3C000

I wonder:

  • what the PRU host address is in an AM263P4 chip
  • what the PRU memory PRU0_DMEM_0 host address is
  • if an example project exists where the PRU memory is accessed from the R5F core so I can take some hints from it
  • if documentation exists about the PRU host address
  • if it is indeed better to locate the queue in the R5F memory space, stated that the R5F addresses are well known
  • if you can suggest other mechanisms to implement a shared queue between R5F and PRU cores

 

Best regards

Michele

  • 0
    TI__Mastermind 24613 points

    Hi Michele,

    Thanks for reaching out and apologies for the delayed response. I am happy to help assist you here.

    I need a little bit of time to get all the information together, but here are a few quick references in the meantime.

    Seems that ChatGPT pointed you correctly, despite a slight nomenclature delta.

    The PRU "DMEM" is described in the AM263Px RA as ICSSM_DRAMx_SLV_RAM.

    All of the associated PRU_ICCS register physical addresses can be found in the associated ICSSM chapter of the Register Addendum (ti.com/lit/ug/spruj57b/spruj57b.pdf)

    We provide documentation on the PRU-ICSS Driver API's for the R5F here: AM263Px MCU+ SDK: Programming

    the PCUICSS API's and hardware #defines can be found here: AM263Px MCU+ SDK: APIs for PRUICSS

    There are also some pru-software-support-package Getting Started Labs that can be referenced here: Getting_Started_Labs « labs - pru-software-support-package/pru-software-support-package - The PRU Software Support Package

    Based on the description you've shared so far, my recommendation would be to implement the Queue in the global/shared SRAM space for optimal access speed/arbitration from both the R5F core and PRU core. There would probably be lopsided access delays for the R5F if the ICSS DRAM is used, but it's still an option.

    What is the expected usage for the Queue data structure and the expected access/functions of the R5F and PRU in this case?

    Best Regards,

    Zackary Fleenor

  • 0 in reply to Fleenor
    Prodigy 30 points

    Hi, Zackary!

    Many thanks for your reply!

    I am implementing a scanner head xy2_100 interface in the PRU0, and while the PRU handles the bit-bang, the R5F core generates the XY 16-bit data, every ms it generates 100 couples x/y.

    So the queue is needed to keep the PRU fed.

    I was thinking to use the PRU RAM because the real time is really needed on the PRU side, while the R5F can tolerate a bigger jitter.

    The queue is accessed by R5F only to write data into the queue, while the PRU just consumes the data.

    The info to access the queue are a couple uint32_t values, one for read ops and one for write ops, that contain a packed structure: the number of operations done and the index, both as 16-bit variables; I think (hope) the access is atomic for the whole structure when read/written as an uint32_t.

    The values are placed in 4-bytes aligned uint32_t variables, that are accessed as whole, and memory barrier are placed before the write index update and after the read index update.

    I already used a similar method in the PRU of the OMAP-L137 and it worked well.

    Question:

    • about the lopsided access from R5F to the queue in the PRU memory
      • I wonder if you may estimate the delay/jitter in the R5F core access
      • if we talk about few cycles from R5F side, I think it can be tolerated if there is a real advantage for the PRU side

    Many thanks again for your help

    Michele

  • 0 in reply to michele sponchiado
    TI__Mastermind 49210 points
    michele sponchiado said:
    I wonder if you may estimate the delay/jitter in the R5F core access

    Hi Michele, The PRU memories are like peripheral memory to R5F(strongly ordered), for a 32bit access from R5f to PRU DMEM is 155ns