• State TI Thinks Resolved
  • Locked Locked
  • Replies 7 replies
  • Answers 2 answers
  • Subscribers 99 subscribers
  • Views 1072 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.

AM5728: PRU to PRU communication conflict with RPMsg

Rob Barton
Expert 2220 points

Part Number: AM5728

Dear TI,

WE are setting up communications between PRU and ARM and PRU to PRU (on one ICSS)

Using the below register settings we can get the PRU to PRU communications to work (interrupt on bit 30 of R31) so one PRU can interrupt the other PRU on ICSS1 but then the rpmsg communication dies.

we have tried this before and after the rpmsg initialization and we specifically or'd our mapping in to avoid changing any rpmsg setup...

How is rpmsg setup these registers so we know how to set this up without causing a conflict.

Thanks.

volatile unsigned long * baseRegisterPtr = 0x00020000;

// Setup the interrupts

// Setup mapping of host interrupts and system interrupts

// PRUSS_INTC_HMR0 Register hex 800 = 2048

// baseRegisterPtr[2048/4] = 0x0;

// PRUSS_INTC_HMR1 Register hex 804 = 2052

baseRegisterPtr[2052/4] |= 0x00010000;

// PRUSS_INTC_CMR# Register hex 400 + (0x4*#) = 1024 + 4*#

// # = 7 in our case so 1024+4*7 = 1052

baseRegisterPtr[1052/4] |= 0x00010000;

// PRUSS_INTC_SECR0 Register hex 280 = 640 clear system interrupts 0-31

// Just clearing the used R30&31 system interrupts since all were cleared in main before

// rpmsg was initialized and set running.

baseRegisterPtr[640/4] = 0x40000000;

// PRUSS_INTC_SICR Register hex 24 = 36

// should clear channels 1  system interrupts

baseRegisterPtr[36/4] = 1;

// Enable the host and system interrupts

// PRUSS_INTC_EISR Register hex 0x28 = 40

// enable channels 1

baseRegisterPtr[40/4] = 30;

 

// PRUSS_INTC_HIEISR Register hex 0x34 = 52

// enable host interrupts 0 & 1

baseRegisterPtr[52/4] = 0x0;

// PRUSS_INTC_GER Register hex 0x10 = 16

  baseRegisterPtr[16/4] = 0x1;

  • 0
    TI__Guru** 108290 points
    Hello Rob,

    1) Could you give me a bit more detail on "we can get the PRU to PRU communications to work... so one PRU can interrupt the other PRU on ICSS1 but then the rpmsg communication dies"?

    2) What version of Linux are you using?

    Regards,
    Nick
  • 0 in reply to Nick Saulnier
    Expert 2220 points

    1.  We are using bit 30 of PRU R31 to interrupt the other PRU core  so:

    XOUT some data pushed to scratchpat

    LDI  R31, 0x2E

    to set the interrupt on one side, and

    WBS R31, 30

    on the other waiting for it to be set to then call

    XIN get the data pushed to scratchpad registers

    This is what I mean getting the PRU to PRU cores to communicate.  The register settings were what we were using.

    2.  the version on linx we are using is:  Xubuntu 16.04.4 LTS

  • 0 in reply to Rob Barton
    TI__Guru** 108290 points
    Hello Rob,

    Summary of your register settings:
    With HMR[1,0] you are mapping channels 0 - 7 to host interrupt 0 except for channel 6, which is mapped to host interrupt 1.
    With CMR7 you map system event 30 to channel 1. Since channel 1 is mapped to host interrupt 0, system event 30 should go towards bit 30 of R31.
    With SECR0, you clear the event flag for system event 30
    With SICR, you clear the system event flag for system event 1 (NOTE: this is not related to channel 1)
    With EISR, you enable events for system event 30.
    With HIEISR you enable host interrupt 0.

    Questions:
    * What version of Processor SDK / PRU SW Support Package are you using?
    * Could you post your resource table? It is possible that your HMR register settings are overriding the RPMsg channel-to-host interrupt mapping, or there may be an issue of mapping system events to the wrong channel.
    * Are you clearing the event from SECR0 after servicing each pru to pru event?

    Regards,
    Nick
  • 0 in reply to Nick Saulnier
    TI__Guru** 108290 points
    Hello Rob,

    I'm going to mark this resolved, but if you want to continue our discussion please post a reply!

    Regards,
    Nick
  • 0 in reply to Nick Saulnier
    Expert 2220 points

    1.  the processor sdk that I'm using is:ti-processor-sdk-linux-am57xx-evm-04.03.00.05

    Do you mean ti-cgt-pru_2.2.1? for the PRU SW Support Package?

    I didn't put the build chain together for Linux so I'm not certain if these are the versions you are looking for.  I know that these are present in the build chain on the Linux development pc being used.

    resource_table_1.h

    The resource tables used were taken from you example, so you should be familiar with them.

    To clear the even we were using the PRUSS_INTC_SICR register, but I have also tried the SECR0 register for clearing.

    Everything works in the debugger when I JUST run the two PRUs, so when they communicate between each other by themselves everything sets and clears properly.

    The problem arises when we introduce rpmsg/our entire application.

    I think the goal of this is to get a clear understanding of which resources are in use by rpmsg and which are free for us to use without conflicting with rpmsg.

    4452.resource_table_0.h

  • 0 in reply to Rob Barton
    TI__Guru** 108290 points

    Hello Rob,

    Yes, I was looking for your SDK version.

    1) SICR/SECR: you should be able to use either register to clear events. NOTE: your code above does NOT clear system event 30; it clears system event 1, which you don't seem to use. If you don't clear a system event after you address it, your code could have problems.

    2) I am not sure how the resource table settings interact with the register settings (e.g. would setting the global host interrupt enable prior to creating the RPMsg channels cause issues?). I need to test this and get back to you.

    Regards,
    Nick

  • 0 in reply to Rob Barton
    TI__Guru** 108290 points

    Hello Rob,

    The ARM sets INTC registers according to the resource table before the PRU begins executing its firmware instructions, so I suspect you are overwriting the RPMsg settings that the ARM made when you write to the INTC registers in your firmware. Try doing all of the settings in the resource table, similar to the attached code. Look for "Change:" for places that I updated the table from the PRU_RPMsg_Echo_Interrupt0 as an example.

    4162.resource_table_0.h

    Regards,

    Nick