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.

MCU-PLUS-SDK-AM243X: Combining the behavior of IPC and PRU-ICSSG

Part Number: MCU-PLUS-SDK-AM243X


I asked the following question a few days ago.

https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1090513/mcu-plus-sdk-am243x-combining-the-behavior-of-ipc-and-pru-icssg

I thought I could solve it just by changing the position of some data.

The following memory areas are no longer used for applications.

Memory mapping range: 0x701E0000 ~ 0x701FFFFF (127KB)

But, The same error occurred again.

Only less frequently, the same data abort "HwiP_data_abort_handler" still occurred.

[Problem]

We want to create a project to transfer EtherNet/IP data to another core for processing.

Therefore, I am trying to transfer data using IPC.

The following configuration is assumed.

1. r5fss0-0 "EtherNet/IP communication"

2. r5fss0-1 "Application processing"

We have incorporated IPC processing into our EtherNet/IP projects.

However, when we try to operate IPC (ipc_rpmsg_echo) and PRU-ICSSG (EtherNet/IP), a data abort "HwiP_data_abort_handler" occurs.

[Additional Information]

I was able to confirm that the problem occurred only when the core of PRU-ICSSG was enabled.

So, I have a question.

Q. Are there any memory access restrictions after starting PRU-ICSSG software (EtherNet/IP)?

  • Hi
    If you do not run the  r5fss0-1 core, and do not use IPC module on  r5fss0-0, do you see the same issue?

    Regards
    Dhaval Khandla

  • Hi
    If you do not run the  r5fss0-1 core, and do not use IPC module on  r5fss0-0, do you see the same issue?

    Yes

    Data abort "HwiP_data_abort_handler"occurs when trying to access shared memory by running only the r5fss0-0 core.

    Best regards,

    Ryohei Yamada

  • Hi
    What is the address of "shared memory"? How is that address being covered in linker file and MPU settings for R5F?

    Is it possible for you to share the snippet of code which you have added in EtherNet/IP example?

    Regards
    Dhaval Khandla

  • Hi
    What is the address of "shared memory"? How is that address being covered in linker file and MPU settings for R5F?

    The location of the shared memory is 0x701D0000.

    This issue will occur no matter which address you change to.

    The settings for the .syscfg file and the linker file are as follows.

    MPU setting "example.syscfg"

    mpu_armv75.$name = "CONFIG_MPU_REGION4";
    mpu_armv75.attributes = "Device";
    mpu_armv75.allowExecute = false;
    mpu_armv75.baseAddr = 0x701D0000;
    mpu_armv75.size = 16;

    Linker setting

    SECTIONS

    /* General purpose user shared memory, used in some examples */
    .bss.user_shared_mem (NOLOAD) : {} > USER_SHM_MEM

    MEMORY

    USER_SHM_MEM            : ORIGIN = 0x701D0000, LENGTH = 0x2000

    LOG_SHM_MEM & RTOS_NORTOS_IPC_SHM_MEM is not used by commenting it out.

  • I think this issue may also be affected by changes in memory mapping.

    In our project we are changing the memory mapping.

    So, I have a question about how to change the memory mapping in MSRAM.

    https://software-dl.ti.com/mcu-plus-sdk/esd/AM243X/08_01_00_36/exports/docs/api_guide_am243x/MEMORY_MAP.html

    Q. What should I do if I try to change from the default memory mapping to the following memory mapping?

    r5fss0-0 uses : 0x70080000 ~ 0x7017FFFF

    r5fss0-1 uses : 0x70180000 ~ 0x701C0000

    Should I also change the settings of the region-based firewall?

    I looked at the following documentation and thought that the firewall would need to be changed.

    AM64x /AM243x Processors Silicon Revision 1.0 - 3.3.2 Interconnect Firewalls

  • Hi, Dhaval.

    We solved this problem.

    Data abort occurred for each of the following two causes.

    1. PRU cores were not reset.

    2. Implementation mistakes in our application

    The PRU behaved erratically without a reset and memory initialization at boot time.

    Therefore, a data abort "HwiP_data_abort_handler" occurred.

     

    I have implemented the process of resetting the core of all PRUs and initializing the memory.

    [API used]

     PRUICSS_resetCore

     PRUICSS_initMemory

    No special operation was required to change the memory mapping.

    Our application now works without occurring data abort.

    Thank you for your support.