硬件观察点终于命中了，停机 PC 却落在一个任务入口的 prepare 序言附近。内存里出现的可疑数值，恰好就是当时几个普通寄存器中的数据。这种现场比“某行代码越界了”更难解释：写入本身可能完全正常，问题发生在另一个执行流随后怎样使用这块内存。

本文沿一次 RH850/U2A 内存异常的记录，说明如何从异常地址找到对象，再从写入 PC 找到汇编和栈槽。现有线索支持继续调查两个相邻任务栈的重叠使用；尚未记录到完整的“写坏返回槽、恢复错误 LP、跳到数据区”过程，因而没有最终根因和修复回归结论。

平台为 G4MH 内核、MICROSAR OS、GHS 工具链与 MULTI 7.1.6。下文使用 TaskA/TaskB、边界 B 和对象地址 C_A，只保留定位所需的地址关系。

一次 RH850 内存异常中，FEPC 和 LP 都指向了一个任务 Context 对象的首地址。这个巧合很容易把排查带向“OS 恢复错了上下文”。但沿着 MAP、结构体布局和栈帧继续看，会发现几件不同的事：对象地址可以作为普通数据被压栈；LP 可以从栈上恢复，也可以从 Context 字段恢复；异常处理函数里看到的 SP，还可能已经属于内核栈。

理解这些关系，才能判断眼前的是被破坏的控制流、保存得很正常的数据，还是另一个时间点留下的现场。

本文讨论 RH850/U2A 的 G4MH 内核与一个 MICROSAR OS 实现。Context 字段和 Region0 用途来自该案例的静态资料，不构成 AUTOSAR 对所有实现的布局规定。示意代码只表达机制。

通用测量核心与 ECU 工程之间的连接集中在平台适配层：它识别实际执行者，读取 STM 时间，形成串行事件，并把统计副本交给报告路径。

对于 TC397 与 AUTOSAR，可以按“Host 模型 → 时间源 → 调度和中断边界 → 周期采样 → 多核发布 → 目标验证”的顺序完成接入。各步骤分别建立一项明确的契约，组合后得到可解释的每核时间账本。

本文使用配套模块中的独立 Hook 模型讲解接口。C99 核心与 Mock 示例已通过 Host 验证；具体 MICROSAR/TASKING/TC397 接入处于 Experimental / Unverified，目标参数和实际 Hook 顺序由工程配置确定。

运行时测量可以分成三个职责：平台产生执行事件，核心维护时间归属，报告路径输出统计结果。显式的分工使同一个算法可以在 PC、裸机和 RTOS 环境中运行。

embedded-runtime-observer 采用 C99 和静态内存实现这一模型。Task、Idle、ISR、调度空档和函数点共用明确的事件边界，在线统计与可选 Trace 各自保留输出状态。v0.2.0 增加独立 Stack Observer，将栈内存需求接入同一报告层。

本文承接时间模型，沿着事件进入核心后的处理过程介绍框架设计。