This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

[参考译文] MSPM0G3519:NMI 回调发生在内部读取/写入数据闪存 (0x41D00000) 的任何收费操作时

Guru**** 2988510 points

Other Parts Discussed in Thread: MSPM0G3519

请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1662790/mspm0g3519-the-nmi-call-back-occurs-on-any-fee-operation-that-internally-reads-writes-the-data-flash-0x41d00000

器件型号: 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 () 之前无条件地擦除所有数据闪存扇区?

 

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    尊敬的 Abhilash:

    建议的根本原因需要进行一项更正:更改费用布局不会使 ECC 与之前固件相比失效。 ECC 与每个物理 64 位闪存字一起存储。 FLASHDED NMI 表示实际存在不可纠正的 ECC 不匹配、通常是由中断/部分写入、没有有效 ECC 的编程、MCAL 写入处理不正确或闪存损坏引起的。

    1. 已校正、当检测到双位 ECC 错误时、0x41D00000 处的读取会生成 NMI。 NMI 源是 FLASHDED;也可以根据 FLASHECCRSTDIS 生成系统复位。 清除擦除的字通常不会导致此错误、因为全 1 和全零字将从 ECC 检查中排除。
    2. 如果 Fee_Write () 的内部扫描读取的是部分编程的或损坏的 64 位字、则它可以触发同一个 NMI。 正确擦除、未使用的区域不应触发该区域。
    3. 在更正后的读取之前、没有要检查的简单“ECC 有效“状态。 为了进行诊断、请使用:
      • 数据未校正别名:0x41E00000
      • 数据 ECC 代码别名:0x41F00000
      • DL_FlashCTL_blankVerifyFromRAM() 确定是否已正确擦除闪存字。
    4. 当固件更新更改收费块布局时、请存储布局版本标记。 如果现有布局不兼容、则在更新期间擦除并重新格式化受影响的数据闪存扇区一次、然后再擦除 Fee_Init ()。 请勿在每次启动时擦除数据闪存。

    此外、MSPM0G3519 具有 16KB 的数据闪存、因此完整的已校正地址范围为 0x41D00000–0x41D03FFF、而不是 0x41D00000–0x41D00FFF。

    验证 AUTOSAR FLS 驱动程序是否使用带有硬件生成 ECC 的 64 位对齐编程、并且在数据和 ECC 编程完成之前绝不允许收费读取字。

    -布赖恩