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.

AM6442: PRU-ICSSG Shared Memory and MSRAM Usage

Part Number: AM6442
Other Parts Discussed in Thread: SYSCONFIG

Hello,

I am currently working on a setup involving the AM64x platform and the PRU-ICSSG module, where I intend to run two separate firmware images concurrently on two different slices within the same PRU-ICSSG instance (e.g., PRU0 and PRU1). One of the slice will run a standard Ethernet firmware and other slice will run a custom firmware dedicated to use GPI/O pins and application-specific logic.

My primary concern is regarding shared memory access and potential conflicts, specifically involving the standard Ethernet firmware.

Does the standard Industrial Ethernet PRU firmware (e.g., the one provided in the SDK) utilize any portion of the Shared RAM (PRU-ICSS Shared Memory) for its operation, or does it solely use its own dedicated Data RAM?

If it does use Shared RAM, which specific address ranges/offsets within the Shared RAM are typically reserved or actively used by the standard Ethernet firmware?

If I define a custom memory region for the PRU-ICSSG using the SysConfig tool, specifically  MSRAM region, how can the custom firmware safely and effectively utilize this allocated MSRAM?

When accessing the defined MSRAM region from either PRU, what is the expected typical latency?

Any guidance on best practices for memory partitioning when running a standard communication stack alongside custom logic on the same PRU-ICSSG would be greatly appreciated.

Thank you in advance for your assistance.

  • Hello Cokk,

    I have sent you a friend request. Please send me a direct message to discuss your multiple e2e accounts and email accounts.

    Additional questions:

    1) which industrial Ethernet firmwares are you using?

    2) what OS is running on A53 in your usecase?

    Regards,

    Nick

  • Hello Nick,

    This is my primary E2E account. The other accounts were created only because I temporarily lost access to this one. There was no intention to misuse the platform.

    Currently, Linux is running on the Cortex-A53 cores. Could you please clarify how this is relevant to the PRU-related behavior or limitation you are describing? In particular, I would appreciate more details on whether the presence of Linux on the A53 impacts PRU operation.

    Regarding Ethernet, I am using the Ethernet firmware provided in SDK 11.02.024 without modifications.

    Regards.

  • Hello,

    If you are using R5F cores to control Ethernet industrial protocols running on the PRU subsystem, then you will have to follow specific steps to get that working alongside Linux A53 cores. If you are using generic PRU Ethernet on the PRU_ICSSG cores and controlling from Linux A53, that is different.

    Your custom code should be able to use the DMEM allocation for that slice without interfering with the PRU Ethernet. I would need to check on the SMEM usage for PRU Ethernet. That may take a few days.

    Regards,

    Nick

  • Hello,

    I found the Ethernet Switch firmware (which takes up all 6 cores in a PRU_ICSSG to implement the switch across 2 Ethernet ports, instead of the 3 cores in a single slice that single EMAC port would take up). The switch firmware does use DMEM0, DMEM1, and SMEM within the PRU subsystem.

    I am waiting on the developers to point me to the dual EMAC code. If I don't respond on Monday or Tuesday, please make a note to ping the thread in 2026.

    Regards,

    Nick

  • Hello Nick,

    I will ping the thread in 2026. Thanks for reply.

  • Hello Nick,

    In addition to the previous discussion, I have another question regarding the PRU-ICSSG.

    When using the PWM module within the ICSSG, we need to set the IEP timer CMP values to drive the PWM logic. My concern is whether modifying these IEP registers might interfere with the Ethernet firmware running on some PRU slices.

    Specifically:

    • Does the standard Ethernet firmware rely on specific IEP CMP registers for its internal timing or frame processing?

    • Is there a risk of resource conflict when using IEP-based PWM while simultaneously running Ethernet tasks on the same ICSSG instance?

    Thank you for your help.

  • Hello, waiting for a response in this thread.

  • Does the standard Ethernet firmware rely on specific IEP CMP registers for its internal timing or frame processing?

    Yes, IEP is used for TSN timesync support by Ethernet firmware as well as scheduling timer triggered tasks.

    Is there a risk of resource conflict when using IEP-based PWM while simultaneously running Ethernet tasks on the same ICSSG instance?

    Yes, since gigabit ethernet firmware on ICSSG uses all 6 PRU cores and shared peripherals like IEP and FDB - resource conflict is bound to happen. We do intend to look at supporting ICSSG based gigabit EMAC as part of roadmap with only using single slice resources, but this is not the case with current SDK version of firmware.

    The best option here is to use second ICSSG for PWM or look at using EPWM peripheral.

  • Hello, how about if i dont use gigabit ethernet? I believe it uses just 3 cores because i can run my custom firmware on other slice. Can you tell me about the shared ram usage of ICSSG firmware in SDK 11.02.024?

    Also, does non gigabit ICSSG firmware use other slices IEP timer resources?

    Do you plan to release a document where you specifically point out the used resources by ICSSG firmware?

    Does PRU ICSSG PWM hardware loads any firmware to PRU Cores?

    Thank you

    Berlam


  • Hello yall,

    I am double-checking with Pratheesh in the background on some of your questions.

    No, we do not plan to release a document that specifically points out the resources used by different configurations of PRU Ethernet at this point in time.

    I do not understand your question "Does PRU ICSSG PWM hardware loads any firmware to PRU Cores". The PWM peripherals are not used by the PRU Ethernet firmware as far as I am aware.

    Regards,

    Nick

  • Hello yall,

    I just re-found this thread. I will try to get a response on the IEP timer question within a few days.

    Regards,

    Nick

  • Yes, both IEP timers are used by the PRU Ethernet firmware.

    This is true regardless of whether the firmware is in switch mode, or dual EMAC mode, and regardless of whether dual EMAC mode is using both PRU Ethernet ports, or only one port.

    Regards,

    Nick

  • The question was not just about IEP timers, how much of shared memory does ICCS/ICCSG ethernet uses?

  • Hi,

    The thread owner is out of office till until week of Feb 17. Please ping the thread if you do not get an update during that week.

    Thank you for your patience.

    Regards,
    Harshith

  • ow much of shared memory does ICCS/ICCSG ethernet uses?

    Memory usage can be found here : mcupsdk-enet-lld/src/per/firmware/icssg/fw_mem_map.h at mcupsdk_next · TexasInstruments/mcupsdk-enet-lld You may need to map to the version of SDK used