AM263P4-Q1: MCU core disconnection

Hi Venkata,

Can you provide more details on the test environment/setup?

-Is this custom hardware or a TI EVM?

-What debugger are you using?

-What software components are installed on your host machine for the testing?

-Any additional information on what the application code is doing at the point of failure and the associated SoC configurations before and after would be beneficial to help us track down possible culprits.

Best Regards,

Zackary Fleenor

Can you provide more details on the test environment/setup?: open Environment 

-Is this custom hardware or a TI EVM?: Custom Hardware

-What debugger are you using? :XDS560V2 system trace Emulator

-What software components are installed on your host machine for the testing? CCS (Code Composer Studio)

-Any additional information on what the application code is doing at the point of failure and the associated SoC configurations before and after would be beneficial to help us track down possible culprits.
   Currently performing open and Closed loop FOC algorithm for Motor control

Hey Venkata,

Thanks for providing those details. The pattern you're describing—normal operation for ~2 minutes, then core disconnection while power and PWM signals remain stable—is typically not a JTAG clock issue (since you've already ruled that out at both frequencies). This usually points to one of a few runtime conditions on the device itself.

Given that you're running a closed-loop FOC algorithm with an inverter on custom hardware, here are the most likely culprits I'd investigate:

1. Watchdog Timer Expiration The AM263P4 has four windowed watchdog timers. If your FOC algorithm is taking longer than expected during certain motor control cycles—especially under load—a watchdog could be firing and resetting the core. This would explain why the PWM continues (it's peripheral-driven) but the debugger loses connection (the core resets). Check your watchdog configuration and servicing intervals relative to your actual FOC loop timing.

2. Thermal Throttling or Reset Under sustained PWM switching with inverter current, the SoC can heat up. The AM263P4 has thermal monitoring built in. If the junction temperature exceeds the thermal shutdown threshold, the device will reset. Verify your thermal design—check if the custom board has adequate cooling and measure actual die temperature if possible.

3. Power Supply Stability Under Switching Noise High-frequency PWM and inverter switching inject significant noise into the power rails. The AM263P4 has multiple supply monitors (VDD, VDDA33, etc.) that can trigger resets if rails dip below thresholds. Measure your power supply ripple and stability under full PWM load with an oscilloscope, especially near JTAG and core supply pins. Poor decoupling or ground return paths are common culprits here.

4. EMI Coupling to JTAG Lines Even though the core resets rather than just losing JTAG, EMI from the inverter can corrupt JTAG communication or trigger unintended behavior. Ensure JTAG traces are shielded, kept away from high-current paths, and properly terminated.

5. Stack Overflow or Memory Corruption A FOC algorithm running at high frequency can exhaust stack space or corrupt heap memory over time, leading to unpredictable resets. Add stack guards and heap checks to your application.

To narrow this down quickly:

• Enable and log watchdog status before disconnection occurs—capture the watchdog timer values and interrupt flags in your application.
• Monitor core temperature via the thermal sensor if your SoC supports it.
• Capture power supply waveforms during the 2-minute window leading up to disconnection.
• Test on a TI EVM (if available) to rule out custom hardware issues.

Can you confirm: Are you seeing any error messages or status codes in CCS before the disconnection, or does it happen silently? And have you been able to capture any debug logs or peripheral status (watchdog, thermal, power monitors) before the core goes offline?

Best Regards,

Zackary Fleenor