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

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

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

Core0 每 10 ms 更新一帧传感器数据，Core1 每 20 ms 读取一次。刚好在 Core1 读取到一半时，Core0 又开始写入：时间戳已经变了，数据数组却仍属于上一帧。程序并不会立刻崩溃，但控制算法拿到的是不一致的快照。

再换一种场景：三个 Core 分别初始化通信、数据和控制模块。Core0 两毫秒就完成，而 Core2 要八毫秒。所有 Core 都完成初始化之后才能开放后续功能，单靠保护共享数据的 Spinlock 还不够。

这两个例子分别对应临界区互斥与阶段会合。前者常用 Spinlock，后者可以用 Barrier 组织；二者都建立在正确的原子操作、内存访问顺序和调度前提之上。我们从 AURIX TC3xx 的底层能力出发，再看 AUTOSAR OS 能提供哪些同步服务。

一台双核 ECU，Core0 每 10 ms 采集一次传感器数据，Core1 根据新数据执行控制算法；同在 Core0 上的诊断任务则每 100 ms 运行一次。它们都属于同一套软件系统，却不应拥有相同的访问权限。

例如，诊断任务需要读取控制状态，但不应随意修改控制任务的私有数据；采样任务要把最新数据送到另一颗 Core，又必须考虑跨核通信和数据一致性。OS Application 的作用，就是把这些执行实体的归属、访问权限和保护边界落实到 OS 配置中。

下面沿着一个采样—控制—诊断系统，结合 AUTOSAR OS R24-11 规范，逐层分析运行模型、权限保护、错误恢复与配置实践。