2. Sitara处理器架构与可靠性关键模块
要对一块 Sitara 板卡做可靠性压力测试，第一步不是写脚本，而是先弄清“哪些硬件单元一旦出问题，系统就会失效或降级”。AM335x、AM437x、AM57xx 这三代芯片虽然都叫 Sitara，但内部结构差异很大：AM335x 是单核 Cortex-A8，AM437x 升级到 Cortex-A9 并强化了 PRU-ICSS 与显示子系统，AM57xx 则是双核 Cortex-A15 加双核 DSP 的异构架构。可靠性测试的对象、可观测点和失效模式，必须按芯片实际结构来定，而不是套用同一份清单。
从电源域看可靠性边界
Sitara 的可靠性首先体现在电源域划分上。以 AM335x 为例，芯片内部大致分为 RTC 域、唤醒域（Wake-up Domain）和核心/外设域（Core/Peripheral Domain）。RTC 域由 VDDS_RTC 独立供电，掉电后仍可由纽扣电池维持；唤醒域包含 Cortex-M3 的 WKUP 子系统、部分 GPIO 和 UART0，用于低功耗唤醒；核心域则承载 Cortex-A8、DDR 控制器、PRU-ICSS、MMC、USB、以太网等主要外设。AM437x 在此基础上增加了显示子系统（DSS）和更完整的 PRU-ICSS，AM57xx 则把 DSP、IVA-HD、GPU 等异构单元纳入独立电源域，并引入更复杂的电压域管理。
做压力测试时，电源域的意义在于：不同域可以独立复位、独立测功耗、独立注入异常。例如测试 DDR 稳定性时，若同时让 USB 大流量传输，两者共享核心域供电，电源噪声会互相耦合，测出的 DDR 误码可能并非 DDR 本身问题。因此合理的做法是先按域隔离负载，再逐步叠加，观察哪个域先出现异常。
CPU 与缓存：压力测试的第一观察点
CPU 子系统的可靠性测试重点不在“跑分”，而在长时间满载下的稳定性与热行为。AM335x 的 Cortex-A8 主频常见 600MHz~1GHz，AM437x 的 A9 可达 1GHz，AM57xx 的 A15 可达 1.5GHz。测试时可用 stress-ng --cpu 0 --cpu-method matrixprod 让核心持续做浮点矩阵运算，同时用 cat /sys/class/thermal/thermal_zone0/temp 每 5 秒采样温度。若温度在 30 分钟内从 45℃ 爬升到 95℃ 并触发降频，说明散热设计或 DVFS 策略存在风险，而不是 CPU 算力不足。
缓存一致性是另一个隐蔽点。AM57xx 的 A15 与 DSP 共享 L3 和 DDR，若 DSP 通过 EDMA 直接写 DDR，而 A15 缓存中仍有旧数据，就会出现“读到旧值”的偶发错误。压力测试中可让 DSP 持续搬运数据、A15 同时校验，观察是否出现校验失败。这类问题在常温下可能几小时才复现一次，必须靠长时间运行和日志比对来暴露。
DDR：误码率与刷新策略
DDR 是 Sitara 系统中最容易受电源和温度影响的单元。AM335x 支持 DDR2/DDR3，AM437x 与 AM57xx 支持 DDR3/DDR3L，部分型号带 ECC。可靠性测试的核心指标是误码率（BER）和刷新稳定性。一个可操作的示例：用 memtester 64M 10 对 64MB 区域做 10 轮读写校验，同时用示波器观察 VDD_DDR 纹波；若纹波峰峰值超过 50mV，误码概率会明显上升。测试温度可从 25℃ 逐步升到 85℃，记录每个温度点的误码次数，形成“温度—误码”曲线。
刷新策略也值得关注。DDR3 在高温下需要更频繁的刷新（如 2x 刷新模式），若软件未根据温度调整，高温下数据保持时间不足，就会出现随机位翻转。测试时可在高温箱中运行 memtester 并对比开启/关闭温度补偿刷新两种配置的误码差异。
PRU-ICSS：实时性不能只看“跑通”
PRU-ICSS 是 Sitara 区别于普通应用处理器的关键模块，包含两个 200MHz 的 PRU 核、共享 RAM、中断控制器和工业以太网外设。它的可靠性指标不是吞吐量，而是确定性延迟和抖动。例如在 EtherCAT 从站应用中，PRU 需要在固定周期内完成帧处理，若因共享 RAM 争用或中断延迟导致周期抖动超过 1μs，从站就可能失步。
测试方法：让 PRU 固件在循环中翻转一个 GPIO，用示波器测量翻转周期。理想情况下周期抖动应在几十纳秒内；若抖动达到几百纳秒，需检查 L3 互连是否被 CPU 大流量访问阻塞。AM57xx 的 PRU 与 DSP 共享更多资源，争用问题更突出，测试时应同时加载 DSP 负载，观察 PRU 抖动是否恶化。
外设与互连：超时与拥塞
MMC、USB、EMAC、I2C、SPI 等外设的可靠性问题通常表现为超时、丢包或数据错位。以 EMAC 为例，AM335x 的千兆以太网在持续满速传输时，若 L3 互连被 DDR 访问占用过多，可能出现接收 FIFO 溢出。测试可用 iperf3 -c 跑 1 小时四线程，同时用 ethtool -S eth0 观察 rx_fifo_overflow 计数是否增长。若计数持续增加，说明互连带宽分配需要调整。
I2C 的可靠性则与总线电容和上拉电阻有关。长走线或挂载多个从机时，上升沿变缓，高速模式下容易误判。测试时可用示波器观察 SCL/SDA 上升时间，若超过规格值（如 Fast-mode 下 300ns），需减小上拉电阻或降低速率。
识别可靠性关键单元的检查表
| 单元 | 关键参数/信号 | 典型失效表现 | 可观测点 |
|---|---|---|---|
| CPU | 主频、结温、DVFS | 降频、死机、计算错误 | thermal_zone、dmesg |
| DDR | VDD_DDR 纹波、刷新率 | 随机位翻转、ECC 报错 | memtester、ECC 计数 |
| PRU-ICSS | 周期抖动、共享 RAM 争用 | 实时任务失步 | GPIO 翻转、示波器 |
| EMAC | FIFO 溢出、互连带宽 | 丢包、吞吐下降 | ethtool -S、iperf3 |
| I2C/SPI | 上升时间、总线电容 | 通信超时、数据错位 | 示波器、内核日志 |
| 电源域 | 纹波、上电时序 | 复位异常、启动失败 | PMIC 寄存器、示波器 |
把这张表当作压力测试的“靶点清单”：每个单元至少设计一项长时间、可量化、可复现的测试，并明确失败判据。只有先识别出影响可靠性的硬件单元，后续的测试脚本、监控手段和判据才有明确的指向，而不是盲目跑负载。