J6P 上，Core1 IRQ 没有保存浮点寄存器，怎么验证它是不是导致出现内存访问错误的根因

最近在J6P的多核 AUTOSAR Classic 项目里排查 Core1 的偶发 Data Abort。集成一批 SWC 后开始出现，出错后板子会卡死，需要复位。奇怪的是，Core1 跑了很多任务，五次独立采集到的首发现场，都集中在同一个 20 ms 任务里的两个 SWC：四次是延迟表读取，一次是对象数组读取。用故障现场的寄存器重算访存地址，和 DFAR 一致，可以确认是用错误索引读到了数组外。部分现场随后在写故障日志时又报 Flash 异常，但两者的因果关系还没查清。

对象数组那次现场比较可疑。源码在浮点转整数前把索引限制在 1..96，对应的关键指令大致如下：

从故障时的寄存器反推，实际参与地址计算的整数是 0x4049999A，恰好也是 3.15f 的 IEEE 754 位模式。异常现场里LR_IRQ 对应的返回位置也刚好是这条 VMOV。另一次独立调试确认，Core1 的核间 IRQ 可以触发调度，后续执行的代码确实会写 S1，而旧版 Core1 的 IRQ 入口没有保存和恢复这组浮点寄存器。

我目前的猜测是：IRQ 恰好发生在 VCVT 和 VMOV 之间，覆盖了 S1，返回后 VMOV 把浮点位模式当成整数索引取走了。但我只能抓到 Data Abort 之后的现场LR_IRQ 可能是前一次中断留下的，而这段代码又会周期性执行，所以无法凭这个快照证明发生在同一轮。另一处延迟表越界也没有抓到同等证据。

试过让 Core1 的 IRQ 入口和出口成对保存、恢复 D0–D7 和 FPSCR。新镜像一次重启后运行约 300 秒未复现，但原问题本来就是偶发的，这个结果只能算初步验证。改动还会增加 IRQ 栈占用和执行时间，所以我不想单凭“改完暂时没再报错”就把底层改动合进去。

想请教有 Cortex-R 或 AUTOSAR OS 移植经验的朋友：

怎么把证据绑到同一次执行？ 用 TRACE32 时，如果只能在 Data Abort 后停住，有没有办法低干扰地记录同一轮 VCVT 的结果、IRQ 进入和退出、以及 VMOV 最后取到的值？我担心逐条断点会改变本来就很窄的抢占窗口。
受控复现应该怎么做才有说服力？ 我想在台架镜像里用一小段汇编，在 VCVT 和 VMOV 之间通过核间握手触发原来的 IRQ 路径，让被调度的测试代码写入已知的 S1 值，最后只把 VMOV 的结果记到 RAM。这样可以对比旧版和补丁版。即使对比成立，还需要什么证据，才能把这个机制和原 SWC 的自然越界联系起来？
故障固定集中在两个 SWC，到底是SWC 自身的问题还是OS中断的问题？