您好！
例如，此行也会清除 DERR 和其它内容
bit_set (sl_tcram1REG->RAMERRSTATUS、TCRAM_RAMERRSTATUS_ADDR_SERR)；//为后续操作清除*
这些位也会清除可能的 SERR 和其它位(如果单个位错误同时发生、则它的详细信息会丢失)、经测试、在 DERR 测试中、SERR 位通常不会被激活、所以它确实隐藏了它们)
/*无论如何清除双位错误*/
sl_tcram1REG->RAMERRSTATUS |= TCRAM_RAMERRSTATUS_DER；
sl_tcram2REG->RAMERRSTATUS |= TCRAM_RAMERRSTATUS_DER；
示例演示应用程序在中止处理程序中包含相同的错误
/*无论如何清除双位错误*/
sl_tcram1REG->RAMERRSTATUS |= TCRAM_RAMERRSTATUS_DER；
sl_tcram2REG->RAMERRSTATUS |= TCRAM_RAMERRSTATUS_DER；
bit_set 的定义
/*SAFETYMCUSW 340 S MR：19.7 "原因- 这是 MISRA 的建议。我们接受这作为编码约定*/
#define bit_set (y、mask) ((y)|=(mask))
为什么即使 bit_set 也不能一致使用？ 上述功能与 bit_set 完全相同、但没有 bit_set、则是错误的... 您是否还会查看代码语法、它即使在一个函数内也是一致的？
寄存器也有类似的正确用法、如果您已经查看了语法、则错误很可能是被捕捉的。。。
sl_tcram2REG->RAMERRSTATUS = TCRAM_RAMERRSTAT_WADDRPAR_FAIL；
由于一个寄存器有如此多的问题、我怀疑这是唯一的问题、因此最可能的类似问题存在于其他地方(至少示例演示应用程序在异常处理程序和 ESM_CALLACK 中有很多、 几乎所有 ESM 通道确认都有|=运算符 ETC，可屏蔽所有可能的 ESM 错误。)...
您是否在 SafeTI 库产品的网页中提供了活动和最新的错误列表？ 我在我的电子邮件中收到了一个错误、因为它看起来像是"几乎每周"发现了错误、所以我怀疑收到的错误是否有效...
还有一些其他的小问题、例如记录的退出 CPU 模式、例如函数 sl_SelfTest_Status_EFuse ()和 sl_SelfTest_CCMR4F ()、声称为 SVC、但实际上与 entry 相同...
