Part Number: AM5728
Other Parts Discussed in Thread: TCAN4550
Hi Expert,
We developed our system based on AM5728 with the AMP architecture. The MPU subsystem runs Linux, and both IPU1 and IPU2 (two Cortex-M4 cores) are activated concurrently. Each IPU core independently controls one SPI peripheral connected to a TCAN4550 chip for CAN FD data acquisition.
1. IPU Firmware Logic
The business logic on the IPU side is streamlined: the core runs an infinite while(1) loop to poll the TCAN4550 status registers continuously. Once valid frames are detected in the FIFO, the full CAN FD payload is read out, followed by local CRC validation on the IPU. If the CRC check passes, the raw CAN FD frame is written to the shared memory region accessible by both A15 MPU and M4 IPU cores.
2. Linux-Side Testing & Fault Phenomenon
Light-Load Burn-In Test (Minimal Test Program Only)
Only a lightweight reader application runs on Linux. Its sole function is fetching CAN FD data from shared memory and counting packet loss or CRC errors. We performed continuous stability burn-in for 2 weeks, with zero CRC failures and zero frame loss throughout the test; communication remained fully stable.
Full-Load Burn-In (Production Application)
When we launch our official production application on Linux, the system concurrently drives RS485 serial ports and Ethernet with high-frequency data transmission for burn-in testing. A reproducible failure occurs: on average, one CAN FD frame with IPU-reported CRC error appears every hour, recurring randomly without fixed intervals.
3. Preliminary Root Cause Hypothesis
CRC errors only manifest under heavy concurrent peripheral load on Linux, while no anomalies occur under light load. Combined with the architectural characteristics of AM5728, our preliminary judgment is insufficient bandwidth of the system L4 interconnect bus.
High-bandwidth peripherals including RS485 and Ethernet on the Linux MPU seize L4 bus access resources heavily. This introduces severe access latency and bus arbitration congestion when the IPU (M4) accesses SPI and TCAN4550 registers over L4. Distorted SPI timing leads to corrupted read-back data bytes, ultimately resulting in local CRC validation failures on the IPU.
We would appreciate your verification on whether this hypothesis holds valid. Meanwhile, we seek your consultation regarding optimization configuration schemes for L4 bus bandwidth, QoS priority assignment, and IPU peripheral access latency tuning.
Best Wishes
Hanc
