[参考译文] MSP430FR5989：MPUSEGIIFG 或 ACCTEIFG 导致 PUC 复位

 对于某些器件、工厂校准可能会受到影响、使得微控制器的运行速度可能比8 MHz 稍高。 但是、TI 会对此保留一定的裕度。 并使用 ATE (自动测试设备)覆盖这些测试项目。

我猜问题可能发生在退出 LPM3后时钟再次启动时、PMM29无法覆盖这一情况。 您可以进行一些测试吗：

1.更改  NWAITS = 1以查看这是否可以解决问题

2.将 LPM3更改为类似 LPM0、看看这是否能解决问题

您好、伊森、感谢您的答复。

为了限制功耗、我们不能使用 LPM0。 另一方面、更改 NWAITS 是一个影响很大的变化、我们不希望这样做、除非我们确信这会导致两个问题。

正如我在第一篇文章中提到的、问题在少数器件中发生、但在发生问题的器件中、会发生多次。 主要、PUC 由 MPUSEGIIFG (信息段中的写入或执行违例)引起。 我们没有在这一段中编写或执行,因此,我们认为这可能是由一些错误行为引起的。 我们想知道您是否注意到了与 MPU 违例相关的任何类型的问题、这些问题可能与其他问题相关。 与在一个器件中一样、出现了由 ACCTEIFG 引起的 PUC、我们想知道与 NWAITS 和访问时间违例相关的问题是否会由于任何原因而触发 MPU 违例。

我不知道硬件如何确定何时发生了访问时间违例。 其中的细节将决定8MHz 限制上有多大的裕度。 但从数据表中看、我并不觉得这是一种温热的模糊感觉。

建议运行条件中的注7指出、允许的时钟频率等于或小于指定的 MAX 值。 但是如果查看标称8MHz DCO 设置、其容差为+/-3.5%。 +3.5%似乎是一个问题。

您可以尝试使用7MHz DCO 设置、看看这是否有用。

您能否检查这些位是否在您的应用中被清除？

根据我的经验、在以下情况下可能会发生这种情况：

1、对信息存储器启用保护

2、MCU 处于异常状态, PC 意外访问信息存储器。

你能试一下 David 的建议吗？  

您好、感谢您的回答。 目前、我不想更改 DCO 频率、因为这可能会对器件的正常运行产生很高的影响。 我们必须首先对其进行评估。 但是、我们在一些器件中遇到的主要故障是信息区域上的存储器保护单元违例。 我们在该区域中设置了防止写入和执行的保护。 n´t 我们不会在这个区域写或执行,所以我们不知道为什么会发生这种情况。 但是、我的问题是要设法确定 NWAITS 值错误与 MPU 违例之间是否存在某种关系。

尝试降低频率的原因是为了检验存在与其相关的 FRAM 访问时间违例的假设。 使用较低的频率。

Javier、您好！

进行更改是为了检查根本原因。 之后、您可以评估采用哪些解决方案。

我无法执行该测试、无论是将 DCO 更改为7MHz 还是将 NWAITS 更改为1。 这里的问题是我们无法接触到具有故障的器件、并且出于安全原因、我们无法实施这些更改、因为它们可能会对器件的正常运行产生重大影响。

n´t 可以在实验室中对测试器件进行这些更改、但到目前为止、我们在实验室中找不到存在故障的器件。 因此、对从未发生故障的器件实施这些更改、如果其中某些更改是问题的根本原因、则不会为我们提供任何信息。

我们正在进行一些测试、以查看我们是否可以在实验室中定期重现故障、从而实施更改并测试是否有任何更改修复了问题。 同时、我们不能测试这种解决办法。

但是、正如我之前在论坛中提到的、无论这些更改中的哪一项可以解决 FRAM 访问时间错误、但我不确定这是否有助于违反内存保护、这也是我们经常遇到的问题。 我最初的问题是想知道是否有人遇到过可能与访问时间错误相关的 MPUV 问题。

从违反 MPU 访问权限中获得系统复位要求您请求该行为。 上电默认为中断。 如果您不使用信息存储器、我看不到任何强制执行复位的原因、因为这似乎不是一个严重错误。 或许是场中一个中断并记录错误、但不是复位。

您好、David。 出于安全原因、我们不能在发生此类错误后继续执行代码。 我们必须启用 PUC、一旦器件复位、读取复位原因、并将器件置于特殊的安全模式。

这里要了解发生该 MPUV 的原因。 由于只有同一批次 MPS430FR5889的少数器件发生、而  其他批次生产的其他器件没有发生这种情况、因此我们怀疑微控制器存在错误行为。

借此机会、我想问一下这个微控制器的 PMM32勘误表。 勘误文档如下所示：

器件可能进入死锁状态 或者执行意外的代码 从 AM 转换到的时长
LPM2/3/4

具体而言、与条件2相关、文档内容如下：

条件2：
以下事件同时发生：
1)器件从 AM 转换为 LPM2/3/4 (例如在 ISR 退出或状态寄存器期间)
修改)、
和
2)请求中断(例如 GPIO 中断)、
和
3) MODCLK 和 SMCLK 均未运行(例如、由外设请求)、
和
4) 4) SMCLK 配置为与 MCLK 不同的频率。

即会发生点1、2和4。 我们使用 LPM3 (我们需要该模式、但不能使用 其他模式)、启用一些中断、并为 SMCLK 配置了与 MCLK 不同的频率。 但关于第3点、我们不确定这意味着什么。 如果点1、2和4同时发生、而此时 SMCLK 正被另一个外设(即 ADC)使用、那么 我们是否处于勘误状态？

看起来条件意味着当其他3个点发生时(最常见的条件) SMCLK 没有运行。 但我们不确定这是否意味着这一点、还是意味着相反。 请帮助我们澄清一下。

当 MCU 在一个 Us 级时间内转到 LPM2/3/4时、会发生该问题。

2)、这意味着当 MCU 进入 LPM 模式时、会生成一个中断请求。 这并不意味着您不能使用任何中断。

3)、这意味着任何外设均未使用这些时钟。 如果 ADC 由 SMCLK 提供、并且 MCU 进入 LPM 模式时生成 ADC 中断。 您不能解决这个问题、因为 SMCLK 由外设使用。 如果在  MCU 进入 LPM 模式时来自 GPIO 的中断和没有其他外设工作、您将满足3)。

您好、伊森、感谢您的回答。 是的、我们可能会出现这种情况、因为在 LPM 模式下没有外设使用 SMCLK。 不过、我认为这不可能是我们遇到此问题的原因、因为这种情况仅在少数器件中发生、显然仅在特定的微控制器批次中发生。

有。 我理解您的担忧。 我已与您指定的销售团队进行过沟通。 这可能是一个过程问题。 但也许只是这样。 请参考以下评论：  

1. 对于这种情况、我建议让 CQE 跟踪此问题。 在完成基准测试和 ATE 测试后、我们将得到一个结论和解决方案、以便了解有关此问题的详细信息。 目前、我唯一的建议是：
   1. 对于第一步、请获取一个可以重新创建此故障的 NG 设备。
   2. 对于第二步、请 创建一个可重现此故障的最小软件示例。
   3. 第三步、将 NG 设备和软件代码发送给我们。

您好、伊森、感谢您的回答。

是的、我们试图让一个"失败"的设备继续进行一些测试、并按照您发送的步骤操作。

此致

为了添加到该线程中、我们注意到未作解释的 MPUV 事件发生(MPUSEGIIFG = 0x0028)与批次 M430FR5989SRGCREP 微控制器之间存在明显相关性。 对于在同一硬件中使用并运行相同代码的 M430FR5989SRGCREP 微控制器、我们已经确定了以下故障发生的统计差异：  

故障转移的商品数量分配的商品总数、具体取决于批次：

具有微控制器批次跟踪代码36I A0KR 和36I A0KJ 的单元：7个单元故障超过74个单元

具有其它批次追踪代码微控制器的单元：0个单元超过71个单元发生故障

累计使用期内的故障数(取决于批次)：  

具有微控制器批次跟踪代码36I A0KR 和36I A0KJ 的单元：在13年累积使用期限内发生25次故障(总共7个单元)

具有其它批次追踪代码微控制器的部件：59年累积使用期限内出现0次故障

这种相关性不一定意味着因果关系、但我们必须考虑所有因素。  

我们不能物理访问已分发的任何单元(包括7个到目前为止发生故障的单元)、但可以远程监控它们、这就是我们计算 MPUV 事件及其特性发生的方式。 批次追踪代码的信息是通过可追溯性记录获得的。 我们未能在我们的设施中重现任何此类故障。  

尊敬的 Javier Navarro：

感谢您分享详细信息。 我仍然建议您参与我们的 CQE。 他们可以帮助跟踪与工厂的很大差异,他们也有更多的经验,如何处理这种推断。  

Unknown 说：

13年累计使用期内发生25次故障(共7次)

请参阅、您可能很难重现此问题、尤其是当它与环境相关时、例如电源或温度。