Other Parts Discussed in Thread: MSPM0G3519
器件型号: MSPM0G3519
器件:MSPM0G3519(Cortex-M0+、0x41D00000 处的 16KB 数据闪存)
工具:EB tresos AUTOSAR BSW—FEE/FLS MCAL 栈
将新的应用程序映像刷写到 MSPM0G3519 后、数据闪存区域 (0x41D00000–0x41D00FFF) 会保留前一个固件会话的残余内容。 启动时、当收费驱动程序 (Fee_Init) 尝试扫描虚拟扇区标头时、它会读取包含与当前数据不一致的 ECC 签名的 8 字节字、这些字由之前固件的收费块布局写入。
这导致 FLASHCTL ECC 校验器直接路由到 NMI 回调、在任何应用程序代码可以运行之前使系统崩溃。
#include <board.h>
#include <Os.h>
#include <Os_tool.h>
#include <Os_kernel.h>
/* Deviation DCG-1 <*> */
/* The debugging symbol of the following function is needed for testing.
This variable prevents inlining optimizations by the compiler or linker that may remove the debugging symbol. */
volatile int NMICbkdummy = 3u;
os_uint32_t boardNmiCallBack(void)
{
if (NMICbkdummy == 3u)
{
NMICbkdummy++;
}
/* Deviation DCG-2 <+2> */
/* This is the default handling of NMI call back. */
#ifdef TESTCASE_ExceptionHandlingCortexM0
/* For testing the common exception handling of OS for NMI */
return 0u;
#else
OS_ENDLESSLOOP();
#endif /* TESTCASE_ExceptionHandlingCortexM0 */
return 0u;
}
问题:
- MSPM0G3519 闪存控制器在读取包含由之前固件计算的 ECC 的残留数据的数据闪存 (0x41D00000) 时是否通过 FAILFDC 生成 NMI? 这是预期行为吗?
- 我们 不仅在显式读取期间观察到 NMI、而且在 Fee_Write () 操作期间也观察到 NMI、该操作在内部扫描活动扇区以定位下一个空闲插槽。 是否预计费用写入扫描会在尚未使用有效 8 字节对齐数据进行编程的区域触发 NMI 回调?
- 是否有一种机制(寄存器,API)可以在读取数据之前检测数据闪存是否包含有效的 ECC 数据(而不触发 NMI)?
- 在部署可改变 FEE/EEPROM 块布局的新固件映像时、TI 建议对数据闪存区域执行的初始化序列是什么? 应用程序是否应该在每次固件更新时调用 Fee_Init () 之前无条件地擦除所有数据闪存扇区?