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.

RTOS/PROCESSOR-SDK-AM57X: PRU-ICSS does not work on A15 with DSP1 on SDK 05.01.00.11

Part Number: PROCESSOR-SDK-AM57X

Tool/software: TI-RTOS

Hello

I'm using AM572x IDK board with TI-RTOS SDK 05.01.00.11. I need to use network stack on PRU-ICSS in dual mac mode on A15 core with DSP1 core, connected by IPC.

When I try to run A15 core with IPC (without DSP) and network stack (based on your IPC & PRU-ICSS examples), all is good: I can ping two PRU2 cores (in dual mac mode) and A15 can communicate with itself.

But when I add DSP1 core with IPC only, cores can communicate by IPC, but I can't ping PRU2 ETH0 and PRU2 ETH1 core.

What do I need to make it work?

With regards,
Alex

  • Hi,

    We are looking into this.

    Best Regards,
    Yordan
  • Alex,

    What's configured in your DSP1 core? Is it conflicting or breaking the ICSS initialization, e.g. interrupt?

    Regards,
    Garrett
  • Hello, Garrett

    Sorry for a long time for an answer.

    We are not reconfiguring IPC interrupts at all (neither A15 nor DSP1).

    Also, we configure DSP1_IRQ_43 to T15 timer (TIMER15_IRQ, IRQ_CROSSBAR_341).

    Adding DSP1 core breaking PRU configuration, as I think, because processor cores (A15 and DSP1) are not generated exceptions.

    With regards,
    Alex

  • Alex,

    Did you check the followings is not overwritten with IPC enabled?

    CSL_xbarMpuIrqConfigure(CSL_XBAR_INST_MPU_IRQ_120, CSL_XBAR_PRUSS2_IRQ_HOST8); /* link ISR */
    CSL_xbarMpuIrqConfigure(CSL_XBAR_INST_MPU_IRQ_121, CSL_XBAR_PRUSS2_IRQ_HOST2); /* RX PKT ISR */
    switchEmacCfg->linkIntNum=CSL_armGicGetGicIdForIrqInputLine(120);
    switchEmacCfg->rxIntNum = CSL_armGicGetGicIdForIrqInputLine(121);

    as well as the emacInitcfg?
    ((ICSS_EmacObject*)emachandle->object)->emacInitcfg = switchEmacCfg;


    Regards,
    Garrett
  • Hello Garrett,

    Firstly, I'm using a dual mac configuration.
    Secondly, I checked PRU2.x interrupt crossbar configuration in registers with JTAG debugger after few time (1-2 minutes after starting) for interrupts, that I used (CSL_XBAR_INST_MPU_IRQ_120, CSL_XBAR_INST_MPU_IRQ_121, CSL_XBAR_INST_MPU_IRQ_122, CSL_XBAR_INST_MPU_IRQ_123) - and all was correct.

    emacInitcfg handles were valid too (as I see values info in the debugger).

    With regards,
    Alex
  • Alex,

    Is the ping broken after your do IPC communication, i.e. messageQ_get or put from/to DSP? or it's broken without even doing mesageQ_open() and simply ipc_start()/ipc_attach()? which ipc procSync mode are you using? ProcSync_ALL or ProcSync_PAIR? processors.wiki.ti.com/.../Ipc_Module

    Regards,
    Garrett
  • Garrett,

    I'm using ProcSync_ALL IPC sync mode.

    And I also using NotifySetup and SharedRegion with IPC.

    Ping doesn't work, if I call Ipc_start() on A15 and DSP1 cores. No other calls of IPC or MessageQ on any core from my code.

    I think that this part of my .cfg file may be useful for you:

    var Ipc = xdc.useModule('ti.sdo.ipc.Ipc');
    Ipc.procSync = Ipc.ProcSync_ALL;
    Ipc.sr0MemorySetup = true;
    var MessageQ = xdc.useModule('ti.sdo.ipc.MessageQ');
    MessageQ.SetupTransportProxy = xdc.useModule('ti.sdo.ipc.transports.TransportShmNotifySetup');
    xdc.useModule('ti.sdo.ipc.family.vayu.NotifyDriverMbx');
    var NotifySetup = xdc.useModule('ti.sdo.ipc.family.vayu.NotifySetup');

    With regards,
    Alex

  • Alex,

    There are some hard coded cross bar settings in IPC  packages/ti/sdo/ipc/family/vayu/NotifySetup.c:

       /* connect mailbox interrupts at startup */

       IntXbar_connect(127, 286);  // eve1 mailbox 0 user 3

       IntXbar_connect(128, 295);  // eve2 mailbox 0 user 3

       IntXbar_connect(129, 251);  // system mailbox 5 user 2

    Which seems to be conflicting with PRSDK 5.1 -

     /* For PRU2 Eth0 */

       CSL_xbarMpuIrqConfigure(CSL_XBAR_INST_MPU_IRQ_127, CSL_XBAR_PRUSS2_IRQ_HOST8);  /* link ISR */

       CSL_xbarMpuIrqConfigure(CSL_XBAR_INST_MPU_IRQ_137, CSL_XBAR_PRUSS2_IRQ_HOST2);  /* RX PKT ISR */

       CSL_xbarMpuIrqConfigure(CSL_XBAR_INST_MPU_IRQ_129, CSL_XBAR_PRUSS2_IRQ_HOST4);  /* TX PKT ISR */

    While the ping is failing, is the link even up?

    see similar cross bar issue here:

    Regards,

    Garrett

  • Hello Garrett,

    I remapped default PRU2.x interrupts to custom (CSL_XBAR_INST_MPU_IRQ_120, CSL_XBAR_INST_MPU_IRQ_121, CSL_XBAR_INST_MPU_IRQ_122, CSL_XBAR_INST_MPU_IRQ_123). That I wrote about above.

    With that config link indication works fine, but ICSS_EmacLinkISR function not calls.

    Then I remapped PRU2.x interrupts to CSL_XBAR_INST_MPU_IRQ_145, CSL_XBAR_INST_MPU_IRQ_146, CSL_XBAR_INST_MPU_IRQ_147, CSL_XBAR_INST_MPU_IRQ_148. With that config link indication works fine too, ICSS_EmacLinkISR function calls, but ping doesn't work yet.

    Thanks, but I cannot find anything useful from your link to the simular issue.

    With regards
    Alex

    P.S. CSL_XBAR_INST_MPU_IRQ_xxx interrupt used for link & Rx packet interrupts on PRU2.0 and for link & Rx packet interrupts on PRU2.1 respectively.

  • Alex,

    The ICSS_EmacRxInterruptHandler function is probably still not called. You can add the icss_emacDrv.c from PDK icss emac driver to your project and check. It might be worth to dump all the CTRL_CORE_MPU_IRQ_XX registers and compare the values before and after adding IPC.

    You can ignore that link - I just wanted to reiterate that crossbar setting typically is the culprit of such integration issues, but it appears to not help : -(

    Regards,
    Garrett
  • Hello Garrett,

    You are right, ICSS_EmacRxInterruptHandler function really still not called.

    I dumped all registers with IPC only on A15 core and IPC on A15 and DSP1 core (I'm using a memory dump tool from CCS debugger). Comparison tool cannot find any difference, but the first configuration is working correctly and second - not working.

    I think that it can be bad timings with peripheral initialization, but how can I understand and correctly fix that?

    With regards,
    Alex

  • Hello Alex,

    What are you trying to do with IPC, just pass messages between cores? If so, you probably don't need to add the Notify module in your .cfg file, and can just add MessageQ.

    Is your application returning from Ipc_Start()? If so, what is the return value? Can you open ROV in CCS (Tools -> ROV Classic) and check for any errors? Is your application hanging? Where is SR0 placed in memory?

    Since you are using IPC.ProcSync_ALL, please make sure you only have HOST and DSP1 in your procList.

    The mailbox and interrupt configuration for IPC on AM572x can be found in the source files in the following directory. Please make sure there are no conflicts here between IPC and PRU-ICSS.

    C:\ti\ipc_3_50_02_02\packages\ti\sdo\ipc\family\vayu

    Regards
  • Hello Sahin,

    Sahin Okur said:
    What are you trying to do with IPC, just pass messages between cores? If so, you probably don't need to add the Notify module in your .cfg file, and can just add MessageQ.

    We are using Notify module to improve communication latency between cores.

    Sahin Okur said:
    Is your application returning from Ipc_Start()? If so, what is the return value?

    Yes, our code exits from Ipc_Start(). We are checking IPC return value to be non-negative, and this check passing.

    Sahin Okur said:
    Can you open ROV in CCS (Tools -> ROV Classic) and check for any errors?

    If you are speaking about Exception module, there are no errors on it.

    Sahin Okur said:
    Is your application hanging?

    No, our task is working. We are using UART log to see Log_* messages and we see, that DSP core answers to messages, that we send to it.

    Sahin Okur said:
    Where is SR0 placed in memory?

    SR0 is placed in DDR memory.

    Sahin Okur said:
    Since you are using IPC.ProcSync_ALL, please make sure you only have HOST and DSP1 in your procList.

    Yes, we are using exactly this configuration for tests.

    Sahin Okur said:
    Please make sure there are no conflicts here between IPC and PRU-ICSS.

    We already checked that. We found some conflicts, fixed them, but without success. We are calling Ipc_start() at the top of the main(), and only then calling PRU-ICSS configuration functions.

    With regards,
    Alex

  • Hello Alex,

    Have you tried using the default MessageQ and Notify transports, TransportShm and NotifyDriverShm?

    What happens if you call PRU-ICSS configuration functions before calling ipc_start?

    Would it be possible for you to share your project so we can take a closer look?
  • Hello Sahin,

    Sorry for a long answer.

    We have not tested your suggestions yet.

    We will share our project for your closer look. We need some time to prepare the project.

    Sorry for your wait again.

    With regards,
    Alex

  • Hello Sahin,

    Sorry for waiting again.

    Our team generates simple projects to repeat that bug. We are using AM572x IDK board & test working with app file generation.

    ti_a15_c66_bug_together.zip

    That archive has two projects: for A15 core and for DSP1 core. They use the config.bld file, that also packed in the archive.

    If you want to build only A15 core (working configuration), you need to set variable coreNames to value ["HOST"] in the host.cfg file. Also, you need to rebuild the a15_0_test project and generate an app file with it only.

    If you want to build A15 and DSP1 cores (non-working configuration), you need to set variable coreNames to value ["HOST", "DSP1"] in the host.cfg file. Also, you need to rebuild a15_0_test and c66_0_test projects and generate an app file with them only (2 projects).

    IP addresses, that configured in the A15 project (file host.cfg):

    • 192.168.4.4/24 for PRU2.0 (PRU2 ETH0)
    • 192.168.5.4/24 for PRU2.1 (PRU2 ETH1)
    • 192.168.6.4/24 for Gigabit (Ethernet0)

    P.S. We generate an app file with pdk/packages/ti/boot/sbl/tools/scripts/AM57xImageGen.sh script.

    With regards,
    Alex

  • Hello Alex,

    Thank you for providing the test project and test details. It will take me some time to reproduce this on my setup. I should have an update for you mid next week.

    Regards,
    Sahin
  • Hello Sahin,

    What about your progress in project checking?

    With regards,
    Alex
  • Hello Alex,

    No updates yet, but I'm still looking at this and haven't forgotten about it.

    Regards,
    Sahin
  • Hello Sahin

    What about that problem? Can you fixed it?

    With regards,
    Alex

  • Hello Alex,

    I'm sorry for the delay here. It's taking me a lot longer to reproduce this than I anticipated. Just to give you an update, I couldn't reproduce this issue behind TI's network so I've acquired another Ethernet card so that I can create a second NIC on my machine. I'm working on doing that now.

    Thanks for your patience.

    Regards,
    Sahin
  • Hello,

    What about my problem? Are you already fixed it?

    With regards,
    Alex
  • Hello Sahin,

    Our team fixed that issue.

    There was a problem in memory regions overlapping for A15 & DSP1 cores: PRU firmware linking in one memory regions for different cores.

    Our team removed PRU firmware linking from DSP1 core & all start working. Thank you for help.

    With regards,
    Alex