根据你描述的现象，核心矛盾是NvM写请求只到了Fee层，没真正下发到Fls完成物理写入，进而引发了后续的读异常和复位后数据丢失问题。大概率是配置或者模块调度逻辑的问题，咱们一步步拆解：

1. Fls_Write未被调用的核心原因 #

Fee作为NvM和底层Flash之间的中间层，它的写操作通常依赖前置步骤（比如块擦除）或者自身的队列调度：

• Fee队列配置问题：检查Fee的最大请求队列长度，如果队列已满，NvM的写请求虽然被NvM接收放入队列，但无法进入Fee的处理队列，自然不会调用Fls_Write。另外，Fee的后台操作优先级是否被配置得过低，导致5ms一次的调度始终没轮到处理写请求？
• 块擦除未完成：如果你的Flash块需要先擦除才能写入，Fee可能卡在擦除步骤（比如擦除时间超过5ms调度周期，每次调度只检查状态但没完成），导致写请求一直处于等待状态，没触发Fls_Write。
• NvM块属性配置：确认NvM块的类型（比如是RAM缓存型还是EEPROM模拟型），如果是延迟写入的配置，NvM可能只是把数据存在RAM缓存里，没触发Fee的实际写入操作，复位后缓存数据丢失。

2. 读取无响应进入NvM_PENDING的DET问题 #

当你发起读请求时，NvM会检查对应块的状态：

• 如果块处于“写请求待完成”的pending状态，而你的DET配置里开启了「未完成操作触发错误检测」的规则，就会直接触发DET。
• 另外，NvM的读请求是否被配置为“写未完成时阻塞”？如果调度逻辑有问题，阻塞后的读请求没被及时唤醒，就会一直卡在NvM_PENDING状态，最终触发DET超时错误。

3. 复位后数据为空的本质原因 #

因为Fls_Write从未被调用，物理Flash里根本没有写入任何数据，复位后NvM从Flash读取自然只能得到默认的0x00。而UDS返回正向响应，只是说明NvM成功接收了写请求并放入队列，不代表数据已经写入Flash。

排查步骤建议 #

• 检查Fee队列与状态：在NvM_Write之后，实时查看Fee的请求队列是否有未处理的写请求，以及Fee的状态机是否处于擦除中/等待调度的状态。
• 验证Fls底层可用性：手动调用Fls_Write写入测试数据，再调用Fls_Read读取，确认Fls本身的读写功能正常。
• 核对模块配置参数：
  • 检查NvM的块配置：NvM_RbWriteEnabled是否开启，NvM_RbBlockType是否匹配你的Flash类型，是否开启了立即写入（而非延迟写入）。
  • 检查Fee的配置：FeeMaxNumberPendingRequests队列长度是否足够，FeeBlockEraseTime是否设置合理（不超过多个调度周期）。
  • 检查DET配置：是否将NvM_PENDING状态的超时错误配置为触发DET，如果是，可适当延长超时时间或优化调度逻辑。
• 跟踪调度逻辑：在5ms调度函数里，确认NvM、Fee、Fls的处理函数是否被正确调用，有没有被其他高优先级任务抢占导致调度不及时。

总的来说，核心问题出在写请求没有穿透到Fls层完成物理写入，配置层面的可能性最高，尤其是Fee的队列、块属性以及调度相关的配置，其次是模块间的状态同步逻辑。

内容的提问来源于stack exchange，提问作者Sivaramakrishna Shriraam