Arm-based microcontrollers forum - Recent Threads

AM2732: AM273x: MSS_MIBSPIA does not receive SPI data in Peripheral mode

Marios Tsavos — Thu, 29 Oct 2026 14:53:39 GMT

Part Number: AM2732

Hello TI Support Team,

I am working with the TI AM273x SoC using Code Composer Studio 20.4 and MCU+ SDK 11.02.00.25. I am experiencing an issue with MSS_MIBSPIA, which I am trying to use as an SPI Peripheral (Receiver) to receive data from an FPGA.

I am unable to get MSS_MIBSPIA to receive SPI data from an FPGA. The FPGA transmits the expected data, and I can observe the SPI clock and data activity using a logic analyzer/oscilloscope. However, the MSS_MIBSPIA receive callback is never invoked.

To investigate the issue, I have tested the following SPI combinations, both of which operate correctly:

MSS_MIBSPIB (TX) → FPGA → RCSS_MIBSPIA (RX)
RCSS_MIBSPIB (TX) → FPGA → RCSS_MIBSPIA (RX)

In both cases, RCSS_MIBSPIA successfully receives the transmitted data. The main configuration change between these tests and my current setup concerns the EDMA instances used, and the pins assigned.

This leads me to suspect that the problem may be related to the configuration, pin multiplexing, interrupt handling, or Peripheral-mode operation of MSS_MIBSPIA, rather than a general SPI communication issue.

Here is my SysConfig configuration regarding the MSS_MIBSPIA interface:

The debugging performed so far is as follows:

The FPGA generates the expected SPI communication sequence.
I can observe clock activity on G19 (MSS_MIBSPIA_CLK).
I can observe data activity on G17 (MSS_MIBSPIA_MISO).
Despite this activity, the spi_rx_callback function is never called.
The other tested SPI combinations successfully receive data using RCSS_MIBSPIA as the receiver.

I understand that, in Peripheral mode, the application must submit an RX transaction before the external Controller begins transmitting. I would appreciate confirmation of whether there are additional requirements specific to MSS_MIBSPIA, including its EDMA request mapping, interrupt configuration, pin multiplexing, or Peripheral-mode setup.

Could you please help clarify the following?

Are there any AM273x-specific restrictions or known issues that could prevent MSS_MIBSPIA from operating as an SPI Peripheral/Receiver?
Are there any additional SysConfig settings or initialization steps required for MSS_MIBSPIA RX operation that differ from those for RCSS_MIBSPIA?
Is there a recommended MCU+ SDK example demonstrating MSS_MIBSPIA receiving data from an external SPI Controller in Peripheral mode, preferably with EDMA enabled?
Are there any known EDMA request-line, interrupt-routing, or resource-allocation requirements specific to MSS_MIBSPIA that I should verify?

Any guidance or recommended debugging procedure would be greatly appreciated.

Thank you for your support.

RE: AM2732: AM273x: MSS_MIBSPIA does not receive SPI data in Peripheral mode

Ming Wei — Thu, 05 Nov 2026 16:17:53 GMT

Hi Marios,

I noticed your syscfg is using 4-pin mode. Have you checked the signal on CS pin?

The other thing you may want to try is to check the "Enable Compatibility Mode" in syscfg.

Best regards,

Ming

RE: AM2754-Q1: AM27542AEZIANJRQ1: power consumption, McASP clocking, OSPI XIP + HyperRAM, and C7x audio software

Shreyansh Anand — Thu, 05 Nov 2026 14:40:46 GMT

Hi Jeankarlos,

[quote userid="724508" url="~/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1695068/am2754-q1-am27542aezianjrq1-power-consumption-mcasp-clocking-ospi-xip-hyperram-and-c7x-audio-software"]5. Software: which C7x audio libraries are available (acoustic echo cancellation, noise suppression, beamforming, crossover/EQ)?[/quote]

These are currently not supported in the audio library, however,

Our SDK offers multiple libraries for DSP:

In the AUDIOLIB, these are the currently supported kernels:

Thanks,
Shreyansh

AM2754-Q1: AM27542AEZIANJRQ1: power consumption, McASP clocking, OSPI XIP + HyperRAM, and C7x audio software

Jeankarlos Lopera — Tue, 03 Nov 2026 22:45:27 GMT

Part Number: AM2754-Q1

Hello,

We are evaluating the AM27542AEZIANJRQ1 (grade E: 4x R5F at 800 MHz, 2x C7x at 750 MHz, 5.5 MB L3) for a new multichannel audio design and would appreciate help with these questions before we start the schematic:

1. Power consumption: the datasheet (SPRSPB0B) says to contact TI. Could you share typical and maximum current per supply rail for grade E, with both C7x cores and all four R5F cores active? We need it to size the PMIC and plan the thermal design.

2. Power supply: is the TPS6522435-Q1 used on the AUDIO-AM275-EVM the recommended PMIC for grade E?

3. Audio I/O: we need about 10 serial audio data lines in total (inputs and outputs, I2S/TDM). Can several McASPs run at the same time in different clock roles (some as clock master, others as slave to an external master) at 48 kHz and 96 kHz?

4. Memory: is booting from OSPI NOR with XIP, plus 16-64 MB of HyperRAM on the second OSPI interface, supported in the MCU+ SDK? Is there a reference design or example?

5. Software: which C7x audio libraries are available (acoustic echo cancellation, noise suppression, beamforming, crossover/EQ)?

6. Does the SDK include a USB device stack (CDC and DFU)?

7. Where is the secure-boot flow documented?

8. Sourcing: our boards are assembled in China. Is there a TI authorized distributor in China that stocks or can supply the AM275x family, and could you share a contact?

9. We also have commercial questions (pricing, samples for prototypes, distributor availability, lifecycle) and some project details we would prefer not to share on a public forum. Could a TI sales representative or FAE for Colombia / Latin America contact us directly at jeankarlos@polaro.com?

Thank you.

Jean Karlos
Polaro

MSPM0G3107: MSPM0G3107: Documentation for IEC 60730 Class B / EN 60335-1 Annex R Certification

Jesper Persson — Thu, 05 Nov 2026 14:01:10 GMT

Part Number: MSPM0G3107

I am writing an Annex R report for the test results of our product, and I would like to ask about documentation for the MSPM0 diagnostic library. I contacted our first point of contact, but was asked to raise the question in this forum for a quicker lead time.

**Background**
The product is to be certified according to EN 60335-1 (Annex R, Table R.1). The software must meet Class B, i.e. include measures that detect faults in, among others, CPU registers, program counter, clock, interrupt handling, variable and invariable memory, addressing, internal data path and external communication.

We have previously used ST microcontrollers. For those, Table R.1 refers to the publicly available [AN3307](https://www.st.com/resource/en/application_note/an3307-guidelines-for-obtaining-iec-60335-class-b-certification-for-any-stm32-application-stmicroelectronics.pdf) (and ST's certified Self-Test Library) as documentation of the applied measures.

**What we use from TI**
We now have a safety-related board with an MSPM0G3107. We use the MSPM0 Diagnostic Library.

The tests run at start-up and we have already documented our own test results, but I need a reference to TI documentation that shows how the library's measures meet the requirements, corresponding to what AN3307 does for ST.

**Questions**

1. Is there a document for MSPM0 that corresponds to AN3307, and that maps the library functions to the measures in IEC 60730-1 Annex H (Class B) / EN 60335-1 Table R.1?
2. May we refer to these documents in our Annex R report, which is submitted to the certification body?

RE: AM2434: AM2434: Shunt-based current measurement using ADC (HW enabled step, continous)

Christian Dev — Thu, 05 Nov 2026 12:32:29 GMT

Hello Karam,

thank you for your answer. Regarding your questions:

- ADC sample averaging is disabled (The element 'avaraging' of adcStepConfig_t is set to zero)

- Theoretically, the ADC should sample only when the low side MOSFET is activ. To verify this, I integrated the dubug pin, which toggles, when the ADC step callback is called. Other than that, I don't know any other method verifying this. As mentioned above, the step is 'hardware enabled and uses the CMP15 event of the IEP as trigger. As I understand the Documentation, the FSM of the ADC remains in an 'Idle' state and does not sample until the hardware event has been triggered.

I hope these answers will help sloving this issue.

Best regards,

Christian

AM2434: AM2434: Shunt-based current measurement using ADC (HW enabled step, continous)

Christian Dev — Fri, 30 Oct 2026 12:26:46 GMT

Part Number: AM2434

Hello,

I would like to use the ADC on the AM2434 to measure the current of a motor phase. I have designed the following circuit for this purpose:

As shown in the (simplified) circuit diagramm, the shunt resistor is not located directly in the motor phase path, but is placed in one of the two gate paths, with the gates receiving a square-wave signal from the EPWM and, in the case of the lower gate, the inverted square-wave signal. Thus, the design already defines that current measurement is only possible when the corresponding gate is activated.

To ensure that the current measurement takes place reliably at a specific point in the time within the EPWM period, it is necessary to use a hardware trigger for the ADC as well as to use continous mode. Since I am already using the IEP for similar purposes, the event ICSS-G0 IEP0 CMP15 (described in Section 12.1.1.3.1 of the TRM) was the ideal choice for me.

However, I'm having trouble measuring the motor phase current correctly - more specifically, the measured current is lower than expected depending on the duty cycle. For example, at a duty cycle of 50%, the measured current is half the expected value. Before I go into more detail, I'd like to note that I've verified the basic conversion forular in the software. To do this, I applied a constant current to the shunt resistor on the PCB. The calculated current in the AM2434 software an the current set on the lab power supply matched in a small measuring series (except for minimal variations around the LSB)

To investigate the issue further, I configured a debug pin that is toggled every time the ADC callback for the specific ADC step is called. You can see two oscilloscope waveforms below. Red shows the EPWM signal, and blue the GPIO signal. These should show that the measurement time (triggered by the IEP CMP15) was configured one time during the EPWM's HIGH phase and one time during its LOW phase (although slight inaccuracies arise due to the method of the measurement, these are negligible).

As I mentioned earlier, I'm measuring an incorrect signal. Although the ADC is measuring the sine wave of the motor phase, it is approximately a factor of 2 smaller. What's causing this? Is the circuit design incorrectly? Or is the ADC configured incorrectly. Here are all the settings:

Channel	ADC_AIN2
Step	3
Mode	HW synchronized, continous
Open Delay	0
Sample Delay	0
Range Check	false
Averaging	none
FIFO	FIFO1

Furthermore, the ADC is configured to only use 'End of Sequence' as interrupt source.

I'd appreciate some help on this topic.

Best regards,

Christian

AM2432: DLR Backup Manager Communication Loss

Wang Hongzhi — Wed, 04 Nov 2026 02:47:16 GMT

Part Number: AM2432

DLR Backup Manager Communication Loss — Problem Analysis Report

1. Summary

This report analyzes two independent defects, both observed sporadically only during the DLR stress test of repeatedly power-cycling ordinary ring nodes:

No.	Defect	Ownership	Status
Issue 1	The DLR Backup Manager spuriously takes over as Active Supervisor on a single-port link down, causing ring role/state churn	TI DLR host driver (SDK 2026.00.00.06)	Fixed locally and verified
Issue 2	PRU firmware host TX queue (Q3/LwIP) deadlock: `busy_m` and the collision slot are never released, permanently breaking all IP communication (including EIP I/O over UDP) on that device	TI `ethernetip_adapter` PRU firmware	Host-side recovery validated; TI root fix pending

Issue 2 directly matches the field symptom: the Manager reports the DLR ring as healthy, yet the Backup Manager cannot be pinged and its EIP I/O connection drops and cannot reconnect.

2. Test Topology

M.port1 ——— N1 —— N2 —— N3 —— N4 ——— B.port1
M.port2 —————————— direct cable —————————— B.port2

M: Manager (Active Ring Supervisor, precedence 1)
B: Backup Manager (Backup Ring Supervisor, precedence 0)
N1..N4: ordinary ring nodes (non-TI devices, ring-node functionality only)
Normally M blocks M.port2; data flows M.port1 — node chain — B.port1; the M.port2↔B.port2 direct cable carries only Beacon/DLR frames.

3. Symptoms

Occurs sporadically after repeatedly power-cycling the ordinary nodes (the Manager and Backup Manager stay powered).
The Manager reports the DLR ring as normal, but the Backup Manager is unreachable.
The Backup Manager times out pinging any device (Manager, nodes); the Manager also times out pinging the Backup Manager.
The Backup Manager's EIP I/O communication fails at the same time (I/O data is sent via UDP/LwIP, sharing the host TX queue with ARP/ICMP).
Breaking and then restoring the ring restores communication, without rebooting the device.

Reproduction: two TI managers configured as Active / Backup Ring Supervisor (both blocking port 2), four ordinary nodes chained in the ring. Keep both managers powered and repeatedly power-cycle the nodes (a few seconds per round). Issue 1 hit 2 times in 12 link-down events; Issue 2 appeared multiple times in the same stress run (always after link recovery).

4. Issue 1: DLR Backup Manager Spurious Takeover on Single-Port Link Down

4.1 Relevant mechanisms in the stock code

(1) Link-down handling

The P0/P1 link-break handlers in icss_dlr.c (EIP_DLR_port0ProcessLinkBrk() / EIP_DLR_port1ProcessLinkBrk()) set the node state to NODE_FAULT, stop that port's IEP watchdog, flush the learning table, and report a ring fault. This path itself is correct.

(2) Beacon-timeout ISR unconditionally re-arms the watchdog

At the entry of EIP_DLR_beaconTimeoutISR_P0/P1 (icss_dlr.c:873 for P0, icss_dlr.c:1022 for P1):

/*Clear the interrupt*/
HW_WR_REG32(intStatusOffset, PORT0_WD_ISR_MASK);
...
/*Need to restart the Watchdog because it's not an auto load timer*/
EIP_DLR_disableIEPWatchdog(dlrHandle, PORT0_WATCH_DOG_ID);
EIP_DLR_enableIEPWatchdog(dlrHandle, PORT0_WATCH_DOG_ID);   /* no link check */

The IEP watchdog is not an auto-reload timer, so it must be re-armed after expiry — hence the unconditional disable + enable. The problem is that this happens before any state/link check: if a port is already down (and will never see a Beacon again), one timeout interrupt that was already pending at link-down (or arrives right after) still enters the ISR and re-enables the watchdog; from then on that port keeps generating timeout interrupts every beaconTimeout (currently 4000 µs) with no way to stop itself.

(3) Backup takeover decision ignores the other port

In EIP_DLR_beaconTimeoutSupProcessing() (icss_dlr_sup.c:880 onwards), the "backup supervisor in FAULT state" branch uses only isSwitchOverPeriodActive to distinguish "first timeout" from "continuous timeout":

if(isSwitchOverPeriodActive == DLR_TRUE)
{
    /* Second and subsequent timeouts: declare the active manager lost */
    EIP_DLR_disableIEPWatchdog(dlrHandle, portNum - 1);
    EIP_DLR_resetStateMachine(dlrHandle);
    EIP_DLR_configSupervisor(dlrHandle);        /* set ACTIVE, send Beacons */
    isSwitchOverPeriodActive = DLR_FALSE;
}
else
{
    /* First timeout: enter the switchover window, stop both watchdogs, enable only P0 */
    EIP_DLR_disableIEPWatchdog(dlrHandle, PORT0_WATCH_DOG_ID);
    EIP_DLR_disableIEPWatchdog(dlrHandle, PORT1_WATCH_DOG_ID);
    EIP_DLR_enableIEPWatchdog(dlrHandle, PORT0_WATCH_DOG_ID);
    isSwitchOverPeriodActive = DLR_TRUE;
}

Nothing in this decision checks whether the other port is still receiving Beacons (nor whether this port's own link is still valid).

4.2 Defect walk-through

With the two code paths above, a single-port link down is enough to trigger takeover:

The node-side port (P1/PHY1) goes down → state machine enters NODE_FAULT, P1 watchdog is stopped;
But the Beacon-timeout interrupt that was already pending at link-down (or arrives right after) still enters the ISR, which re-enables the P1 watchdog unconditionally at entry;
P1 is down, so no Beacon arrives and timeouts recur every 4 ms, re-entering the FAULT branch;
The first timeout arms the switchover window (isSwitchOverPeriodActive = TRUE); the second executes resetStateMachine + configSupervisor and takes over as Active Supervisor;
Meanwhile the Manager's Beacons on P2 never stopped. Per DLR semantics, the backup may take over only when neither port receives Beacons;
The firmware then clears the ACTIVE bit by precedence (backup 0 < manager 1), and the host runs transitionToBackupSupervisor() on the idle→fault event, demoting back to Backup within about 1 ms.

4.3 Field event trace

[55347868] P1 LINK DOWN drvLS=01
[55347868] DLR_P1_BRK link=0 node=NORMAL en:status=0x00230000
[55347868] FDB FLUSH port1 entries=33
[55347868] DLR -> FAULT  node=FAULT ring=2
[55347868] BCN_TO_P1 node=FAULT sm=0x0201
[55347872] BCN_TO_P1 node=FAULT sm=0x0201
[55347872] DLR RESET SM (previous node=FAULT)
[55347872] DLR RESET SM (previous node=IDLE)
[55347872] SUP -> ACTIVE   EN=0x27        <-- spurious takeover
[55347873] ISR_P2 evts=0x0108 ... [RING_FAULT_TRANS STOP_BOTH_TMR ...]
[55347873] SUP -> BACKUP   EN=0x23        <-- demoted about 1 ms later

Within the same observation window: P1 LINK DOWN 12 times, BCN_TO_P1 7 times, 2 spurious takeovers (about 1 in 6; sporadic).
During the same period the Manager side shows no role change, so the churn happens only on the backup side.

4.4 Impact

Each hit produces a brief "dual supervisor / role flap" on the ring, and the Backup Manager sends its own Beacons;
The takeover path calls EIP_DLR_dRAMInit(), which clears the ActiveSup MAC/IP in SMEM; the demotion path does not restore them; updateSupervisorDetails() may write addr.supMACAddress and the learning exception table as 00:00:00:00:00:00;
CIP status, the participant table, and ring-fault counters are repeatedly reset, degrading long-term DLR network stability.

4.5 Fix (local)

Location (stock file)	Change
`icss_dlr.c` beacon-timeout ISR (P0/P1)	Check this port's live link (MDIO) first; on link down → stop the watchdog, clear `TIMER_RUNNING/START_TIMER`, set `isrAck`, and return without re-arming
`icss_dlr.c` beacon-timeout ISR (P0/P1)	Record genuine timeouts in `lastBcnTimeoutTick[port]` for the backup decision
`icss_dlr.c` NORMAL branch + `EIP_DLR_switchToNormal()`	Clear `isSwitchOverPeriodActive` so a previous fault's switchover window does not persist
`icss_dlr_sup.c` backup/FAULT branch	Add a peer-port criterion before takeover: other port link up + its watchdog running + no new timeout within an observation window → conclude "the other port still has Beacons", do not arm, do not take over
`icss_dlr_sup.c` switchover arm branch	Change from "stop both watchdogs, enable only P0" to "keep both watchdogs running" so the peer-port criterion is meaningful when evaluated
`icss_dlr.h`	Add `lastBcnTimeoutTick[2]` and two link/watchdog query declarations

Genuine manager-loss scenarios are unaffected: when both ports go silent, the other port times out too, the criterion fails, and takeover still happens; worst-case takeover time increases from about 2× to 3× beaconTimeout.

4.6 Verification

With the new firmware under the same stress test (repeated node power cycling), the event trace no longer shows SUP -> ACTIVE; on P1 link down it shows BCN_TO P1 ignored (link down); legitimate takeovers occur only when the Manager side is truly silent.

5. Issue 2: PRU Firmware Host TX Queue (Q3) Deadlock

5.1 Stock queue protocol and driver TX path

(1) Queue descriptor (PRU1 DRAM, shared by host and firmware)

Offset	Field	Written by	Meaning
+0	`rd_ptr`	PRU	firmware read pointer
+2	`wr_ptr`	host	host write pointer
+4	`busy_s`	host	host ownership flag
+5	`status`	firmware	bit0 `busy_m` (firmware busy), bit1 collision
+6/+7	`max_fill` / `overflow`	—	statistics

In addition, each port has a collision slot at colStatusAddr+1/+2: when the target queue is busy the host moves the frame into the collision queue and writes (queue<<1)|1; the firmware clears it after consuming the collision queue.

(2) Driver TX path (MCU+ SDK icss_emac.c, ICSS_EMAC_txPacketEnqueue(), switch mode)

/* 1. Read status.busy_m */
collision_queue_selected = (temp & 0x00000100U);      /* Check the "busy_m" bit */
if(collision_queue_selected != 0U)
{
    hostStatPtr->txNumCollision++;
    /* 2. Check whether this port's collision slot is already occupied */
    col_queue_already_occupied = HW_RD_REG8(colStatusAddr + port);
    if(col_queue_already_occupied != 0)
    {
        hostStatPtr->txDroppedPackets++;
        hostStatPtr->txCollisionDroppedPackets++;
        return ICSS_EMAC_ERR_COLLISION_FAIL;           /* No space in collision queue */
    }
}
...
/* 3. If free, put the frame into the collision queue and set the port's collision slot */
collision_status = (queuePriority << 1) | 0x0001U;
HW_WR_REG8(colStatusAddr + port, collision_status);

So: once the firmware leaves a queue's busy_m set indefinitely, every transmission takes the collision path; the host sets the collision slot on the first attempt, the firmware never clears it, and every subsequent transmission is dropped at step 2 with ERR_COLLISION_FAIL, while txDroppedPackets/txCollisionDroppedPackets keep increasing.

5.2 Field evidence

(1) TX counter deltas around a ping (Backup Manager port1; driver statistics plus TX return-code counts)

Counter	Before ping	After ping	Delta
`txBC` (driver statistic)	32	32	0
`txNumCollision` (driver statistic)	21818	22368	+550
`txCollisionDroppedPackets` (driver statistic)	21814	22364	+550
`ERR_TX_NO_LINK` return count	666073	666073	0
other drops (queue full, etc.) return count	10318	10318	0

That is: the link is up (no NO_LINK drops) and queues are not full, yet every transmission fails on the collision path — an exact match for the code path in 5.1. Over the same period port2 shows txBC +534 (all broadcasts leave via port 2, which faces the Manager's blocked port).

(2) Raw queue descriptor values in the fault state (read from PRU1 DRAM)

P1 Q0 wr=1088 rd=1088 used=0 busy=0 busym=0 ovf=0
P1 Q1 wr=11a4 rd=11a4 used=0 busy=0 busym=0 ovf=0
P1 Q2 wr=1328 rd=1328 used=0 busy=0 busym=0 ovf=0
P1 Q3 wr=15a4 rd=15a4 used=0 busy=0 busym=1 ovf=0
P1 colStatus=7   (= (3<<1)|1, Q3 collision slot asserted)

The deadlocked queue is P1 Q3 (ICSS_EMAC_QUEUE4, the LwIP transmit queue);
The queue itself is empty (wr==rd, used=0) — no data backlog; the stuck part is the handshake bits;
status.busy_m=1 and colStatus=7 are held together while all other queues are normal.

(3) Formation time

[1918964] P1 LINK UP drvLS=101
[1919003] DLR -> NORMAL node=NORMAL ring=1
[1919919] *** TXQ P1 STUCK colStatus=7 busy_m=1 ***

The deadlock forms after link restore, DLR returning to NORMAL, and the host resuming enqueues to Q3 — i.e., the firmware fails to complete or properly abort an in-flight TX transaction across the link/ring state transition.

5.3 Ownership conclusion

State	Set by	Cleared by	Notes
Queue `status.busy_m`	PRU firmware	PRU firmware	The stock driver only reads this bit (as a TX-path condition); no code writes `busy_m`
Collision slot `colStatusAddr+1/+2`	Host (TX path, step 3 in 5.1)	PRU firmware (after consuming the collision queue)	The stock driver only writes non-zero values, never 0; `+0/+3` are host acknowledgements to the firmware
Queue `wr/rd`	Host writes wr, firmware writes rd	—	In the field `wr==rd`: data is empty

Therefore the indefinitely held busy_m=1 and collision-slot assertion are a firmware state machine that failed to converge, not a driver logic error; link events, port control registers, and DLR state transitions never make the firmware release these two states.

5.4 Impact

Q3 is the LwIP transmit queue; in this product EIP I/O data is sent over UDP/LwIP, sharing Q3 with ARP/ICMP → I/O and ping fail together (the PLC-side connection drops and data stops updating);
DLR/Beacon (firmware-internal path) and L2 forwarding are unaffected, which is why the Manager still sees the ring as healthy;
The receive direction is fine: the learning table still learns the peer MAC and the DLR state machine works.

5.5 Recovery validation and host-side workaround

Experiment: in the busy_m=1 && wr==rd state, having only the host clear the busy_m bit in status, clear the colStatus collision slot, and set wr = rd restores transmission immediately (collision counters stop, ping and EIP I/O recover);
This also proves the PHY, driver TX path, and LwIP are all fine; the only unreleased states are the two handshake states owned by the firmware;
A host-side workaround can therefore periodically check queue descriptors and, after several consecutive samples (about 600 ms) of busy_m=1 && wr==rd, perform the same clear; the outage per event is shortened from "permanent" to under 1 s;
Limits of the workaround: all Q3 transmissions still fail during the 600 ms window; if the PLC connection timeout is shorter than that, the connection still drops and reconnects; repeated deadlocks on the same port within a short interval require throttling the recovery action (to avoid repeatedly clearing firmware state).

Risk note: this clears firmware-owned handshake bits and is used only in the verified "busy_m=1 && used=0" case; rebooting the device recovers from any anomaly.

5.6 Recommended TI fix

The PRU firmware should complete or roll back in-flight host TX transactions on link down/up, port reset, and DLR state transitions, releasing the queue busy_m and the corresponding collision-slot assertion; at minimum it must not leave a "queue empty but busy_m=1" state after link recovery. Attach the field data and descriptor records from sections 5.1–5.3.

6. Excluded Hypotheses

Hypothesis	Evidence	Conclusion
Learning table points the peer MAC to the blocked port 2	Learning-table query shows the peer MAC on PORT1; after clearing, it re-learns on PORT1 and ping still fails	Excluded
Port linkStatus cache stuck	Driver cache matches live PHY state; link state is correct after a real link down/up experiment	Excluded
ARP/L3 configuration	ARP table shows the correct Manager entry; local IP/mask correct	Excluded
Manager-side anomaly	Manager side: no role change, no Rapid Fault, no abnormal Announce Suppression	Excluded
Whole-host TX stall	Only Q3 is stuck; Q0–Q2 idle and the EIP real-time path healthy	Narrowed to Q3

7. Requests to Texas Instruments

Confirm Issue 1 and provide a driver fix: on a single-port link down, the backup supervisor's beacon-timeout ISR must not re-enable the watchdog of the down port, and the takeover decision must verify that neither port is receiving Beacons. Please confirm the change direction in icss_dlr.c / icss_dlr_sup.c and provide an SDK release containing the fix.
Fix Issue 2 in the PRU firmware: on link down/up, port reset, and DLR state transitions, complete or roll back any in-flight host TX transaction and release the queue status.busy_m plus the corresponding collision-slot assertion. Please confirm whether "queue empty (wr==rd) while busy_m=1 and colStatus remains asserted" is a known firmware defect.
Confirm interface semantics: is the colStatusAddr+1/+2 collision slot guaranteed to be cleared by the firmware after it consumes the collision queue? Is status.busy_m only cleared by the firmware's internal transmit-complete event?

RE: AM2432: DLR Backup Manager Communication Loss

Archit Dev — Thu, 05 Nov 2026 11:19:31 GMT

Hi Wang

[quote userid="643794" url="~/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1695098/am2432-dlr-backup-manager-communication-loss/6530915"]May I know the ETA for the new Industrial Comms SDK? [/quote]

I am checking on this internally. I'll share an update by tomorrow on this.

[quote userid="643794" url="~/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1695098/am2432-dlr-backup-manager-communication-loss/6530915"] Looking forward to your update on points 1 & 3.[/quote]

For the issue 1, from the preliminary analysis it looks like we may not require re-arming the IEP Watchdog in case of beacon timeout. We are still testing the changes.

Also, thanks for reporting the new issue with the detailed findings - I'll keep working on it and keep you posted.

Regards,
Archit

AM2612: SBL executes PBIST successfully, but subsequent HSM FW load or application load causes random resets only on MCU+ SDK 26.01.00.08

Ichikawa Tatsuya — Thu, 05 Nov 2026 09:57:55 GMT

Part Number: AM2612

Environment

Device: AM2612
Boot mode: OSPI Boot
SDK that works: motor_control_sdk_am261x_10_02_00_07
SDK that fails: mcu_plus_sdk_am261x_26_01_00_08
SBL Execution flow:
1. LBIST
2. PBIST
3. HSM Runtime FW load
4. Applicaion load

Problem Description

After adding PBIST execution to SBL, PBIST itself passes successfully, but subsequent boot processing becomes unstable.

Observed behavior:

PBIST reports PASS.
After PBIST completion, the system resets unexpectedly.
Reset location is not constant.
Sometimes reset occurs during HSM Runtime FW loading.
The reset point changes from boot to boot.
This behavior appears only with MCU+ SDK 26.01.00.08.
The same SBL concept works correctly with motor_control_sdk_am261x_10_02_00_07.

Because the failure point is random and changes every run, it does not appear to be a straightforward software logic issue.

PBIST code

The SBL executes PBIST as follows:

status = SDL_DPL_init(&dpl_interface);

CacheP_disable(CacheP_TYPE_L1P | CacheP_TYPE_L1D);

rvPBIST = SDL_PBIST_selfTest(
    SDL_PBIST_INST_TOP,
    SDL_PBIST_NEG_TEST,
    SDL_BIST_MAX_TIMEOUT_VALUE,
    &PBISTResult);

if ((rvPBIST == SDL_PASS) && (PBISTResult == true))
{
    rvPBIST = SDL_PBIST_selfTest(
        SDL_PBIST_INST_TOP,
        SDL_PBIST_TEST,
        SDL_BIST_MAX_TIMEOUT_VALUE,
        &PBISTResult);
}

CacheP_enable(CacheP_TYPE_L1P | CacheP_TYPE_L1D);

After PBIST:

Drivers_open();

Bootloader_socLoadHsmRtFw();

Bootloader_socInitL2MailBoxMemory();

Board_driversOpen();

Bootloader_parseAndLoadMultiCoreELF();

Questions

Are there any known differences in PBIST handling between motor_control_sdk_am261x_10_02_00_07 and mcu_plus_sdk_am261x_26_01_00_08?
After PBIST completion on AM261x, are there any mandatory recovery steps such as:
- ECC initialization
- OCRAM initialization
- Mailbox RAM initialization
- Memory scrub
- PBIST reset release sequence
that must be executed before HSM FW loading?
Are there any changes in MCU+ SDK 26.01.00.08 that make the post-PBIST recovery requirements different from older SDKs?

Additional Observations

PBIST itself always reports PASS.
Disabling PBIST removes the issue.
The failure location changes every boot cycle.
This behavior suggests possible RAM/ECC corruption or incomplete memory recovery after PBIST rather than a deterministic software bug.

Could TI provide guidance on the recommended AM261x boot flow when PBIST is executed before HSM FW loading and application image loading?

Best Regards

AM2434: AM243x ICSSG EtherCAT Slave: DC System Time Difference (0x92C) takes 6–7 s to converge, and sometimes much longer

Marvin Hsu — Wed, 16 Sep 2026 09:28:01 GMT

Part Number: AM2434

Setup

AM2434x, ICSSG EtherCAT Slave (TI PRU firmware)
Topology: Master → SLAVE 1 → SLAVE 2 → SLAVE 3 → SLAVE 4( The device under observation is SLAVE 4 )
DC with Sync0 enabled, Cycle Time = 2 ms, reference clock is SLAVE 1
0x930 = 4096, 0x934 = 0, 0x935 = 12 ( All default values)
DC registers value are read on the slave side every 1 ms and record( waveforms see attachment )

Observation

With the same hardware, the same firmware and the same configuration, Only reboot the system, leads to two different results:

	Normal	Abnormal
Convergence time of 0x92C	12.5 s → 19.7 s, about 7.2 s	11.5 s → 26.5 s, about 15 s
Peak of 0x932	~3400	saturated at 3969 (= 0x930 − 0x7F) for about 7 s
Steady-state 0x932 / 0x92C / 0x928	1584 / −36 ns / 2089 ns	1576 / −38 ns / 2094 ns

In both cases 0x930 / 0x934 / 0x935 are identical, the steady-state values are almost the same, and the DC loop behaviour (0x932 integration, sawtooth pattern) has the same shape. The only difference is the time needed to converge.

Questions

Q1. In the normal case, 0x92C still needs about 7 s to converge within ±100 ns, counted from the start of the cyclic BWR to 0x910. Is this convergence time too long? With a 2 ms cycle and the default settings 0x930 = 4096 and 0x935 = 12, is this the expected convergence time, or does TI have a typical value we can refer to?

Q1-1. Is it possible to shorten the convergence time by tuning registers such as 0x930 or 0x935(or else)?

Q2. In the abnormal case the convergence time extends to about 15 s. What could be the cause? Apart from simply waiting for the DC loop to converge by itself, is there any recommended measure to avoid such unstable convergence time?

Attachment

Waveforms of the normal and abnormal power-ups (0x92C, 0x932, AL State) with the convergence time markers, together with the static register values of both cases.

RE: AM2434: AM243x ICSSG EtherCAT Slave: DC System Time Difference (0x92C) takes 6–7 s to converge, and sometimes much longer

Marvin Hsu — Thu, 05 Nov 2026 09:31:51 GMT

Hi Aaron,

Please find the requested information below.

1. PDO lengths

The data comes from the DUT_In_Station1_…test_8…pcap attached last time (the MainDevice configures 0x1C12/0x1C13/0x1600/0x1A00 through CoE SDO).

SubDevice	RxPDO 0x1600 (SM2, LWR)	TxPDO 0x1A00 (SM3, LRD)
AM2434 DUT	17 entries, 48 bytes	14 entries, 40 bytes
Beckhoff ESC IP (2 devices)	16 entries, 44 bytes	14 entries, 40 bytes
Total	LWR 136 bytes	LRD 120 bytes

DUT mapping (index:subindex (bits)):

RxPDO 0x1600: 6040:00(16), 607A:00(32), 60FF:00(32), 6071:00(16), 6080:00(32), 6072:00(16), 60B1:00(32), 60B2:00(16), 2110:01(16), 2110:02(16), 2110:03(16), 2000:00(8), 6060:00(8), 2124:01(32), 2124:02(32), 2126:00(32), 2127:00(32)
TxPDO 0x1A00: 6041:00(16), 60F4:00(32), 6064:00(32), 606C:00(32), 6077:00(16), 2111:01(16), 2111:02(16), 2111:03(16), 2120:01(32), 2120:02(32), 2125:01(32), 2125:02(32), 2001:00(8), 6061:00(8)

The Beckhoff ESC IP devices use the same mapping, without the last RxPDO entry 2127:00 (32 bits).

2. ICSS memory dumps

See dumps.zip below , it contains 6 memory dump files (DUT in Station 1~3 & Old/New Sdk), both starting at address 0x30080000, with a length of 0x40000

e2e.ti.com/.../dumps.zip

Thanks,
Marvin

RE: AM2754-Q1: AM27542AEZIANJRQ1: power consumption, McASP clocking, OSPI XIP + HyperRAM, and C7x audio software

Aryamaan Chaurasia — Thu, 05 Nov 2026 09:13:43 GMT

Hi Jean Karlos,

[quote userid="724508" url="~/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1695068/am2754-q1-am27542aezianjrq1-power-consumption-mcasp-clocking-ospi-xip-hyperram-and-c7x-audio-software"]4. Memory: is booting from OSPI NOR with XIP, plus 16-64 MB of HyperRAM on the second OSPI interface, supported in the MCU+ SDK? Is there a reference design or example?[/quote]

XIP is supported with both, OSPI NOR and HyperRAM. However this is supported during runtime and not during booting. The OSPI controller which we have does not have any provision to supoprt XIP during Booting. Please refer to the 5.4.1.1.1.2 OSPI Loading Process from the AM275x TRM, the same also applies for the xSPI boot mode:

For use cases involving performing XIP during runtime, We do have documentation explaining how to enable XIP, and we also have example applications that perform XIP operations with OSPI NOR and perform XIP operations with HyperRAM.

Regards,
Aryamaan

RE: MSPM0G3519: ECC detected for FEE Dataflash region

Francois Charlot — Thu, 05 Nov 2026 08:36:09 GMT

Hi Rana,

Let me try to answer your questions.

Does this mean TI recommends disabling or ignoring ECC errors for the FEE region?
We assume that you need to have the flash ECC enabled in general, so we recommend that you ignore the FLASHDED errors just for the FEE region.
What is the risk of keeping it enabled? Is the ECC reporting misleading errors in the dataflash (FEE) region?
Please see my former post. Using the FEE may lead to ECC errors because e.g. interrupted/partial write, but such errors should not be treated as safety issues as their impact is not as bad as reading incorrect opcodes from the program flash. If data errors occur in the FEE, other mechanisms such as the CRC check that you mentioned below suffice to close the safety issue.
Is disabling the configuration "FEE_USE_ECC_ADDRESS_SPACE" enough or there are other errors which trigger NMI handler that are recommended to ignore/disable (ex: RAM ECC)?
I do not think that disabling FEE_USE_ECC_ADDRESS_SPACE is the way to go, because doing so would mean that the whole FEE data space is not ECC corrected, meaning that even single bit errors which are correctable would not be corrected.
I will let the expert confirm when he returns next week, but I believe that the proper way is for the NMI handler to check if the NMI source is FLASHDED; then, if that's the case, check if this error happened while the FEE driver was being executed.
RAM ECC is not related. Leave it enabled as per your requirements.
Regarding the ECC double bit detected on an ECU, is this considered a real error or a fake one and CRC check is enough for the the Fee blocks.
It is a real error because indeed an ECC double error was detected but as said above, it should not be treated as if this FLASHDED error were related to reading incorrect opcodes in the program.

Best regards,
François.

MSPM0G3519: ECC detected for FEE Dataflash region

Rana Abed — Mon, 02 Nov 2026 19:23:48 GMT

Part Number: MSPM0G3519

Hello all,

I have encountered an ECC double bit error in the dataflash region which is causing continous reset.

I noticed a statement in the FEE User Guide: "The system integrator shall add hooks into the NMI handler to ignore any NMI faults generated from the regions dedicated to the FEE module. NMI can happen on reset scenarios when the FEE algorithm attempts to read some corrupted ECC flash region"

Does this mean TI recommends disabling or ignoring ECC errors for the FEE region?
What is the risk of keeping it enabled? Is the ECC reporting misleading errors in the dataflash (FEE) region?
Is disabling the configuration "FEE_USE_ECC_ADDRESS_SPACE" enough or there are other errors which trigger NMI handler that are recommended to ignore/disable (ex: RAM ECC)?
Regarding the ECC double bit detected on an ECU, is this considered a real error or a fake one and CRC check is enough for the the Fee blocks.

LP-AM261: External Flash changed to GD?

Ted Huh — Wed, 04 Nov 2026 09:29:07 GMT

Part Number: LP-AM261

Hello ASM Team,

It seems like the external flash on LP-AM261 has changed to Gigadevice but there's no description about this on ti.com. and also SDK does not have prebuilt SBL. maybe Uniflash flasher also will fail.

do you have sbl and flasher for this new external flash?
in case of you don't have those, is it helpful that i build example code for you and customers?

Regards,

Ted

RE: LP-AM261: External Flash changed to GD?

Lakshya Verma — Thu, 05 Nov 2026 08:26:50 GMT

Hi Ted,
We have a LP-AM261 with Gigadevice flash , but that version board is currently not available on TI.com
We have support in SDK for Gigadevice flash via SysConfig.
You need to change Flash Configuration in Sysconfig.

MSPM33C321A-Q1: mcan_single_message_tx some issue

Colombo Carlo — Thu, 08 Oct 2026 08:24:42 GMT

Part Number: MSPM33C321A-Q1

Hi Everybody ,

I m on M33 Launchpad , using the mcan_single_message_tx out of the SDK - and Launchpad is stdalone ( I dont have a CAN analyzer )

I was expeting to be able to see 1 message on CAN everytime I press the Button : now I can see the first one and only it - so just one message

there is no Breakpoint set

please where am I wrong ? why I cannot see after another button press anothe rmessage ? ( fyi I checked and any time I press the button it is recognized by the code )

thank you

BR
Carlo

RE: MSPM33C321A-Q1: mcan_single_message_tx some issue

Colombo Carlo — Thu, 05 Nov 2026 08:26:02 GMT

Hi Ella ,

thakn you , the one shot message was the reason

thank you

BR
Carlo

RE: AM2754-Q1: AM27542AEZIANJRQ1: power consumption, McASP clocking, OSPI XIP + HyperRAM, and C7x audio software

Tushar Thakur — Thu, 05 Nov 2026 04:33:34 GMT

Hi Jean Karlos,

[quote userid="724508" url="~/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1695068/am2754-q1-am27542aezianjrq1-power-consumption-mcasp-clocking-ospi-xip-hyperram-and-c7x-audio-software"]6. Does the SDK include a USB device stack (CDC and DFU)?[/quote]

The current SDK offering does not support USB. But the above mentioned USB class driver(i.e. CDC & DFU) is planned to be supported in future SDK releases.

Regards,
Tushar

AM2434: AM243x HS-SE: encrypted MCELF (ENC_ENABLED=yes) does not boot, while signed-only MCELF boots (MCU+ SDK 12.01)

Vit Triska — Mon, 26 Oct 2026 14:36:02 GMT

Part Number: AM2434

Hello,

device: AM243x, HS-SE (SMPK/SMEK programmed, KEYREV = 1)
SDK: MCU+ SDK AM243x 12.01.00.33
SBL: custom SBL OSPI based on sbl_ospi, signed with SMPK (and encrypted SMEK). The encrypted/not encrypted SBL itself boots correctly.

I tested the SDK example "examples/hello_world (r5fss0-0_freertos)", built with DEVICE_TYPE=HS:

#1:
ENC_ENABLED=no:
The signed "hello_world.mcelf.hs" boots fine.
```bash
$(MAKE) -C ${CCS_PROJECT_DIR} -f makefile_ccs_bootimage_gen OUTNAME=${BuildArtifactFileBaseName} PROFILE=${ConfigName} MCU_PLUS_SDK_PATH=${MCU_PLUS_SDK_PATH} CG_TOOL_ROOT=${CG_TOOL_ROOT} CCS_INSTALL_DIR=${CCS_INSTALL_DIR} CCS_IDE_MODE=${CCS_IDE_MODE} DEVICE=am243x DEVICE_TYPE=HS CUST_MPK=${IMI_VS18VS26_KEYS_PATH}/smpk.pem CUST_MEK=${IMI_VS18VS26_KEYS_PATH}/smek.txt ENC_ENABLED=no
```

#2:
ENC_ENABLED=yes:
The signed and encrypted "hello_world.mcelf.hs" does not boot.
```bash
$(MAKE) -C ${CCS_PROJECT_DIR} -f makefile_ccs_bootimage_gen OUTNAME=${BuildArtifactFileBaseName} PROFILE=${ConfigName} MCU_PLUS_SDK_PATH=${MCU_PLUS_SDK_PATH} CG_TOOL_ROOT=${CG_TOOL_ROOT} CCS_INSTALL_DIR=${CCS_INSTALL_DIR} CCS_IDE_MODE=${CCS_IDE_MODE} DEVICE=am243x DEVICE_TYPE=HS CUST_MPK=${IMI_VS18VS26_KEYS_PATH}/smpk.pem CUST_MEK=${IMI_VS18VS26_KEYS_PATH}/smek.txt ENC_ENABLED=yes
```

Observations:

With "ENC_ENABLED=yes", "makefile_ccs_bootimage_gen" invokes "appimage_x509_cert_gen.py --enc y". This appears to encrypts the whole MCELF, including the ELF header.

However, "Bootloader_parseELFMeta()" in "bootloader_mcelf.c" checks for the plaintext "\x7fELF" magic value immediatelly after the certificate. When the image is encrypted, this check fails because the ELF header is no longer readable in plaintext.

Questions:

1. What is the recommended way to boot an encrypted MCELF application on an AM243x HS-SE device?
2. Is the `ENC_ENABLED=yes` flow expected to work with MCELF images, and if so, what additional steps are required?
3. If encrypted MCELF images are not currently supported, what is TI's recommended approach for protecting application confidentiality in OSPI flash?
4. Is support for encrypted MCELF boot planned in the next SDK release?

Thank you for your help.

Best regards,
Vit

RE: AM2434: AM243x HS-SE: encrypted MCELF (ENC_ENABLED=yes) does not boot, while signed-only MCELF boots (MCU+ SDK 12.01)

Prashant Shivhare — Thu, 05 Nov 2026 04:30:59 GMT

Hello,

There are no technical limitations to support the MCELF encrypted boot. It's just that we didn't have any customer requirements yet to support the same. I have created an interal requirement now but this will most likely not make it to the next SDK release (v12.2) because of the time constrainsts.

We recently integrated MCELF encrypted boot in the SDK for AM275 devices

https://github.com/TexasInstruments/mcupsdk-core-k3/commit/5bc2a9d8a7012119aadecc856766441d01a5dcea

https://github.com/TexasInstruments/mcupsdk-core-k3/commit/0b7e0fef691af3c69d1c0d467c4d149fe13ffaa9

https://github.com/TexasInstruments/multicore-elf/commit/4673330653e9b71fbc08424271bda93f132d4a36

github.com/.../98566b6230a428ce9924255f29257d8b5e636a19

The patches I shared are simply the port of these commits so you can be sure that the official support will be more or less the same. It may divert a little but nothing that would affect the authentication of the application images.

Please let me know if any further clarifications are required.

Regards,

Prashant

RE: AM2432: DLR Backup Manager Communication Loss

Wang Hongzhi — Thu, 05 Nov 2026 01:42:14 GMT

Hi Archit,

One more thing. We found a new issue during testing, details are as follows. Could you help check and confirm whether the proposed fix is reasonable?

DLR Ring Supervisor Overwrites the Last Active Node with Its Own Address

SDK: ind_comms_sdk_am243x_2026_00_00_06 (also present in 2025_00_00_08) File: source/industrial_comms/ethernetip_adapter/icss_fwhal/icss_dlr_sup.c

Symptom

After a cable break between two ring nodes, one of the DLR Object attributes 6/7 (Last Active Node Port 1/2) contains the supervisor's own IP/MAC instead of the node adjacent to the fault. Issuing the CIP Verify_Fault_Location (0x53) service once and reading the attributes again returns the correct values.

Root cause

Runtime trace on the supervisor (1 ms resolution):

[57534] LSTAT RX P1 ... ACTNODE P1 <- 192.168.1.5  (link_status)     <- correct
[57534] DLR -> FAULT
[57534] LSTAT RX P2 ... ACTNODE P2 <- 192.168.3.88 (link_status)     <- correct
[57536] BCN_TO_P2 ... ACTNODE P2 <- 192.168.1.4   (bcn_timeout_self) <- overwritten 2 ms later

Three code locations in the driver (SDK 2026 line numbers):

icss_dlr_sup.c:2202/2222: the Link_Status source is correctly recorded into activeNode[portNum].
icss_dlr_sup.c:2238: the transition to FAULT disables only the PORT0 beacon watchdog, regardless of which port received the frame.
icss_dlr_sup.c:955/971: the FAULT-state beacon-timeout handler unconditionally writes the local address into activeNode[that port].

The ring is open, so the supervisor's own beacons never return on either port; the watchdog that was left armed expires about 2 ms later and overwrites the node just recorded with the supervisor's own address. If the Link_Status is received on Port 2 the overwrite is deterministic (only PORT0 is disabled); if the Link_Status arrives after the timeout, the attribute looks correct, which is why the problem appears intermittent.

Proposed fix (2 changes)

When entering FAULT after a Link_Status, disable the watchdogs of both ports and clear DLR_TIMER_RUNNING | DLR_START_TIMER on both ports.

 nodeState = NODE_FAULT;
 EIP_DLR_disableIEPWatchdog(dlrHandle, PORT0_WATCH_DOG_ID);
+EIP_DLR_disableIEPWatchdog(dlrHandle, PORT1_WATCH_DOG_ID);
+/* clear DLR_TIMER_RUNNING_MASK | DLR_START_TIMER_MASK on both ports */

On a FAULT-state beacon timeout, write the local node only when the port link is down; when the link is up, send a Neighbor_Check_Request and start the neighbor timeout instead (if the neighbor does not answer, the existing neighbor-timeout handler writes the local node, which matches the DLR definition of "no Neighbor_Check_Response").

-if ( ... ) { activeNode[port] = deviceIP; }
+if (EIP_DLR_isPortLinkUp(dlrHandle, port) == DLR_FALSE) {
+    activeNode[port] = deviceIP;      /* no link: the supervisor really is the end of this segment */
+} else {
+    EIP_DLR_sendNeighborCheckReq(dlrHandle, port);   /* ring open beyond this port: verify the neighbor */
+}

Verification

Both fault-detection paths (Link_Status-triggered and beacon-timeout-only) no longer produce bcn_timeout_self; attributes 6/7 keep the real nodes on both sides.
After the ring is restored the watchdogs are re-armed (IEP WD ctrl=0x00010001, enP0=1 enP1=1), and a subsequent fault is still detected and located correctly.

Questions for TI

Are these two changes consistent with the DLR specification and the intended design of the ICSS DLR driver?
For a FAULT-state beacon timeout on a port whose link is up, we no longer write the local node but send a Neighbor_Check instead. Is this acceptable, or would you recommend simply keeping the beacon watchdogs disabled in FAULT state?
Can this be fixed in a future SDK release?

Thanks & Regards,

Hongzhi

RE: AM2432: DLR Backup Manager Communication Loss

Wang Hongzhi — Thu, 05 Nov 2026 01:32:34 GMT

Hi Archit,

Thanks for your update. May I know the ETA for the new Industrial Comms SDK? Could we get a pre-release build for validation in advance? Looking forward to your update on points 1 & 3.

Thanks & Regards, Hongzhi

AM13E23019: PGA connection to CMPSS for three phase over-current protection

Hang Yang — Mon, 02 Nov 2026 03:28:45 GMT

Part Number: AM13E23019

Hi Experts,

My customer are developing motor control application, they want to use PGA + CMPSS for over-current protection. They have below questions:

Can PGA OUT connect to CMPSS?

The TRM has shown that the PGA_OUT_INT has connected to CMPSS, however, the sysconfig only shows "connect to ADC" and there are only options for PA, not PGA_INT_OUT

Neverthess, one of the PA, for example PA17 in this screen shot, is shared with the PGA_OUT, so we may use PGA_OUT intead of PGA_OUT_INT to route PGA to CMPSS. I have tested this setup would work, but could you please comfirming this is a supported function? And if this is the only way to route PGA to CMPSS, then the PGA_OUT_INT is not connected to CMPSS, we may need to fix the TRM.

How to support three phases?

Even with the above method, there only 2 out of 3 PGAs that has its PGAx_OUT shared with a CMPSS input. The PGA1_OUT does not share any CMPSS input.

May I know why desigin the signal this way? And how to achieve 3 phases over-current protection?

Regards,

Hang