• State Resolved
  • Locked Locked
  • Replies 1 reply
  • Subscribers 32 subscribers
  • Views 85 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.

Original question:

AM2612: AM2612 Package Selection (ZCZ vs ZEJ) & Industrial Communications (OSPI Level Shifter / ICSSM Profinet & Lwip / SysConfig...

AM2612: AM2612 PROFINET Device Support on ICSSM1 and ZEJ Package for 2-Port Design

Jack
Guru 10186 points

Part Number: AM2612
Other Parts Discussed in Thread: SYSCONFIG, LP-AM261, DP83826E

Hello TI Team,

We are developing a custom AM2612 board based on the Industrial Communications SDK PROFINET Device example.

The current PROFINET Device example is configured to use ICSSM0. In our current Custom SysConfig configuration, PROFINET uses ICSSM0, while General Ethernet / ICSS-EMAC uses ICSSM1.

For our final custom board architecture, we are considering moving the PROFINET Device application from ICSSM0 to ICSSM1. We would also like to evaluate the ZEJ package for a future production board because of PCB area and pin-assignment constraints.

Could you please clarify the following?

  1. PROFINET on ICSSM1
  • Is the current use of ICSSM0 in the PROFINET Device example only due to TI validation coverage, or is the PROFINET firmware/FWHAL architecture functionally tied to ICSSM0?
  • Is it technically possible to run the PROFINET Device application on ICSSM1?
  • If supported, what changes are required for migration from ICSSM0 to ICSSM1?
    • SysConfig configuration
    • Board and pinmux configuration
    • Generated source files
    • Interrupt and event mapping
    • FWHAL configuration
    • PROFINET stack adaptation
    • PRU firmware selection or build configuration
  • Does TI officially support and validate PROFINET Device operation on ICSSM1, including 2-port operation? If not, please clarify whether this would be considered a customer-owned implementation.
  1. ZEJ package support for 2-port PROFINET Device

We have already completed basic PROFINET testing using the LP-AM261 platform. For the production board, we are considering the AM2612 ZEJ package.

Could you please confirm:

  • Are there any known limitations when implementing a 2-port PROFINET Device with the ZEJ package?
  • Are there any mandatory ICSSM/PROFINET signals available on ZCZ but unavailable on ZEJ?
  • Which ICSSM instance, ICSSM0 or ICSSM1, is recommended for a 2-port PROFINET Device design using the ZEJ package?
  • Does TI provide a recommended pin assignment, pinmux example, reference design, or validated custom-board configuration for ZEJ package based 2-port PROFINET?
  • Are there additional restrictions related to Ethernet PHY reset, MDIO, reference clock, interrupt/event routing, or PRU-ICSS pin assignment when using ZEJ?

Our goal is to build a custom 2-port PROFINET Device board using the actual ZCZ or ZEJ package pin assignment, rather than retaining the LP-AM261 board configuration.

Thank you for your guidance.
Best Regards, 
Jack Cha

  • +1
    TI__Mastermind 39823 points
    Hi Jack,
    Thanks for the detailed questions. I'll address each section based on our current findings, including a related thread on this exact topic that is still being tracked with our engineering team.
    1. PROFINET on ICSSM1
    • Is ICSSM0 use just validation coverage, or architecturally required? Currently, the official AM261x PROFINET Device Demo example only lists ICSSM0 as the supported instance, and the SysConfig PROFINET module force-writes the ICSS instance to "ICSSM0" in generated code (profinet1.icss_emac[0].instance = scripting.forceWrite("ICSSM0")).
    • Is ICSSM1 technically possible? We have an active internal thread on this identical question (AM2612 ZEJ, PROFINET on ICSSM1). Our engineer's response there was: "ICSSM1 is able to support the 2 ports needed for PROFINET but we haven't done any ICSSM1 integrations before. I quickly tried to enable this with SysConfig and got some internal errors from SysConfig itself (not PROFINET). I've informed the responsible team and will follow up once I have a result." That thread remains open/unresolved as of now.
    • Bottom line: We do not currently have an officially validated PROFINET-on-ICSSM1 migration path. No documented procedure exists yet for SysConfig, interrupt/event mapping, FWHAL, PRU firmware build, or stack adaptation. Until our engineering team confirms feasibility and provides a validated configuration, this would be considered a customer-owned/experimental effort. We will follow up once that internal investigation concludes and update you here.
    2. ZEJ Package for 2-Port PROFINET Device
    • Why ICSSM0 doesn't work on ZEJ: Confirmed — several signals required for the second MII port of ICSSM0 are not bonded out on the ZEJ package, so a 2-port PROFINET design using ICSSM0 is not possible on ZEJ.
    • Recommended ICSS instance for ZEJ: ICSSM1 is the confirmed/recommended instance for 2-port industrial Ethernet (including PROFINET) on the ZEJ package. This was explicitly validated in a separate E2E thread where our HW expert reviewed a customer's SysConfig file using PRU-ICSS1's MII0/MII1 interfaces mapped to two DP83826E PHYs, and confirmed the pinout as valid.
    • Mandatory MDIO requirement: Both PHYs must share the same single PRU-ICSS1-MDIO bus — a second MDIO instance is neither required nor supported. This was explicitly confirmed in that thread.
    • Reference design / pinout: There is no formal reference design or datasheet-published pinout for ZEJ 2-port PROFINET specifically. However, the validated pin-level mapping from the DP83826 thread (PRU-ICSS1 MII0/MII1 + shared MDIO) is directly applicable, since the same ICSS-to-Ethernet signal mapping applies across industrial protocols (EtherCAT/PROFINET/EtherNet-IP).
    • Important distinction to flag: That validated pinout used the generic ICSS_EMAC SysConfig module — not the dedicated PROFINET application module. As noted above, the PROFINET module currently force-writes ICSSM0 and throws internal SysConfig errors when an engineer attempted to override it to ICSSM1. So: pin-level MII/MDIO routing to ICSS1 on ZEJ is confirmed feasible at the hardware/pinmux level, but the PROFINET protocol stack/FWHAL itself is not yet validated running on ICSSM1. These are two separate layers of the problem — only the former has been demonstrated so far.
    3. SDK Version Requirement — Please Confirm
    Separately, please confirm you are on the correct SDK for ZEJ. The AM261x Industrial Communications SDK did not originally support the ZEJ package at all (no TI EVM existed with ZEJ, so SysConfig threw errors when switching packages). We have since released ZEJ support via a request-only build — AM261X-EARLY-SDK, requestable at ti.com. Make sure you're on this SDK build (not the general-purpose MCU+ SDK, which lacks the "TI Industrial Comms Toolkit" module required for PROFINET/EtherCAT PRU-ICSS configuration).
    Summary Table
    Question Answer Status
    Is ICSSM0 architecturally required for PROFINET? No — official example just defaults to it Validation-only limitation
    Pin-level MII/MDIO routing to ICSSM1 on ZEJ Feasible, TI HW-reviewed Confirmed
    Full PROFINET stack/FWHAL on ICSSM1 Not yet validated; SysConfig throws internal errors when forced Not officially supported (under investigation)
    ZEJ + 2-port PROFINET reference pinout No formal TI reference design; ICSS_EMAC-based example reviewed by TI Partially available
    ICSSM0 2nd MII port on ZEJ Not bonded out — ICSSM1 required for 2-port on ZEJ Confirmed
    SDK required for ZEJ package AM261X-EARLY-SDK (request via ti.com) Required
    We will continue tracking the alternate thread on ICSSM1 PROFINET feasibility and post an update here as soon as a resolution is made available. In the meantime, I'd recommend proceeding with your ZEJ hardware pinmux plan (ICSSM1 + shared MDIO), since that layer is confirmed, while treating the PROFINET-stack-on-ICSSM1 migration as pending TI validation.
    Please let us know if you have further questions.
    Best Regards,
    Zackary Fleenor