MCAL-Crypto与FEE抢占Fls驱动问题与对策说明

Harlan

1. 问题

1.1 旧版调用链与风险

旧版 Crypto 密钥装载驱动依赖 Fls：循环调用 Fls_MainFunction() 等待空闲，以局部数组 TempKey[32] 提交 Fls_Read()，再循环调用 Fls 主函数等待结果。FEE 也经 Fls 执行异步作业。
若 Crypto 抢占正在执行 Fls 主函数的 FEE 路径，又调用 Fls_MainFunction()，就可能重入同一 Fls 作业。即使通过防重入标志跳过第二次调用，抢占方原地忙等也会阻止被抢占方恢复，最终可能超时。
若 Fls 已接受异步读取，而 Crypto 等待超时后返回，Fls 保存的目的指针还可能指向已失效的栈数组。因此，旧方案同时面临主函数重入、抢占方忙等和缓冲区生命周期风险。

1.2 影响的驱动版本

MCAL V3.0.0及以前

2. 解决对策

2.1 驱动更新

本次更新三个 Crypto 驱动文件：Crypto_Lld_KeyManage.c、SchM_Crypto.c 和 SchM_Crypto.h。新版密钥装载直接操作 EFM 并同步等待命令完成，不再调用 Fls_Read() 或 Fls_MainFunction()；由 Crypto 引起的上述 Fls 主函数重入及异步栈缓冲区失效链路随之消失。

2.2 双状态检查与抢占推演

但 Crypto 与 FEE/Fls 仍共用 EFM。Fls 已登记请求但尚未下发命令，或异步命令已完成但尚未结算时，都可能出现 Fls 作业 PENDING、EFM IDLE。仅凭硬件空闲就清除 EFM 状态，可能破坏 Fls 尚未读取的错误结果。
因此，Crypto_KeyManage_LoadAESKey() 在 AREA12 内、首次写 EFM 前，同时要求 Fls_GetStatus() == MEMIF_IDLE 且 EFM 为 IDLE；任一条件不满足就不执行装载，返回 E_NOT_OK，不在抢占方忙等。
在 AREA12 屏蔽全部相关 Fls 执行者的前提下：Crypto 抢占已登记的 Fls 作业，会被 PENDING 检查拒绝；Fls 想抢占 Crypto，则不能在 AREA12 内插入。Crypto 退出后 Fls 再登记属于顺序执行，而非中途抢占。

2.3 失败上报

失败时，密钥装载函数调用 Det_ReportRuntimeError() 记录，并返回 E_NOT_OK。当前 HCU 配钥调用方丢弃该返回值；用户需根据 DET 记录安排失败处理，驱动不会因此自动中止或重试当前 HCU 作业。

3. 注意事项

1. 屏蔽范围： Crypto临界区采用 AREA12，优先级 BASEPRI=0x20，优先级更高的中断仍可进入。须确认所有 Fls/EFM 调用者及任务切换都受 AREA12 约束；Crypto 与 Fls 各自的 SchM 不是同一把跨模块锁。
2. 接口边界： 避免并发绕过 Fls 上层作业登记、直接调用 EFM LLD。例如 Fls_Lld_ReadFlash() 的 NVR 路径可能操作 EFM，却不会使 Fls_GetStatus() 显示 PENDING。
3. 失败管理： DET 只记录诊断，不会停止当前 HCU 作业；Fls 占用、EFM 忙、命令超时或硬件错误目前都被记录为 CRYPTO_E_OPERATION_TIMEOUT，用户需根据 DET 记录安排失败处理，驱动不会因此自动中止或重试当前 HCU 作业。

4. 驱动文件

Crypto_Fls_Reg_Release_1.0.zip

xianghan

这类帖子，放到MCAL下面就行

YunTu Forum