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.

[参考译文] MSP430FR5720:部分FRAM已清除为0x00

Guru**** 2393725 points
Other Parts Discussed in Thread: MSP430FR5720

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

https://e2e.ti.com/support/microcontrollers/msp-low-power-microcontrollers-group/msp430/f/msp-low-power-microcontroller-forum/591915/msp430fr5720-part-of-fram-cleared-to-0x00

部件号:MSP430FR5720

您好,

我的客户使用MSP430FR5720时遇到问题。
关闭电源后系统突然停止工作,客户发现部分代码存储器被清除为0x00。

3个PC (总共60个)出现了该问题,并且在问题发生后,地址0xF000至0xF58C被清除为0x00。
这是代码区。 这3个电脑重新编程,然后正常工作。
客户尝试重现问题,但到目前为止未成功。 因此,问题概率似乎很低。

我在客户主板上发现的一个问题是AVCC和DVCC在主板上完全分离,通电计时如下所示:
DVCC先通电,然后AVCC在毫秒/秒顺序后通电。
根据数据表(SLASE35B),DVCC和AVCC应以相同的定时启动。
5.3 部分有一个注释。
“(1) TI建议从同一电源为AVCC和DVCC供电。 AVCC和DVCC之间0.3 V的最大差值可以是

在通电和操作过程中可容忍。"

问题:
1)如果DVCC和AVCC分别加电会发生什么情况? 是否可能将FRAM的一部分清除为0x00?
2) FRAM数据清除到0x00的可能原因是什么?

谢谢,此致,
Kot

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

    您好,Kot,

    感谢您的发帖。

    问题:
    1)如果DVCC和AVCC分别加电会发生什么情况? 是否可能将FRAM的一部分清除为0x00?
    2) FRAM数据清除为0x00的可能原因是什么?[/QUOT]

    对于#1,结果是不可预测的。 如果您违反规范,则很难准确预测故障将如何发生,因为它显然超出了零件设计的范围。 我想说,它可能会在某种程度上导致FRAM清除,例如,它会导致设备执行不稳定。

    对于2号:

    可能导致清除FRAM数据的情况不同。 由于FRAM可以像RAM一样写入,因此很可能是代码导致FRAM以0写入,或者设备的异常执行导致错误写入FRAM。 为了更好地了解根本原因,我们需要了解更多有关情况的信息。 首先,客户是否启用MPU来保护其代码? 这被视为最佳做法,对于帮助防止错误写入非常重要。 客户如何启用MPU (他们是使用CCS/IAR中的MPU工具,还是在其代码中手动启用MPU)? 他们是否在代码中的某个位置正常执行FRAM写入操作?

    但是,无论采取什么措施,他们都应该解决AVCC和DVCC分别出现的问题违反了规范,因此我们无法将其作为根本原因排除-即使它不是此问题的根本原因, 它可能会导致其他问题,因此必须修复。

    此致,

    Katie

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

    您好,Katie:

    感谢您的快速回复,并对我的延迟回复表示抱歉。

    对于#1,我知道结果是不可预测的。
    我从客户那里得到了通电波形。 请参阅附件。
    DVCC打开到AVCC打开之间存在~411msec时间间隔。
    在此期间,AVCC不是从外部供电,但在引脚处可以看到~2.4V电压。

    对于#2,客户在其代码中手动使用MPU。
    事实上,他们最初没有使用MPU。 他们看到系统在重启后经常挂起。
    实施MPU后,3个电脑仅出现3次问题。
    我要求客户确认他们在没有MPU的情况下看到的问题与MPU完全相同。

    没有MPU:地址0xF630已损坏。 数据损坏似乎是随机的。
    使用MPU:地址0xF0000至0xF58C被清除为0x00。 (两个结果相同。 另一个1件未检查)

    谢谢,此致,
    Kot

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

    您好,Kot,

    感谢您提供更多信息,并感谢您耐心等待我的回复-我一直在国际旅行。

    对于#1:~400ms是处于此超规格状态的很长时间。 如果这在客户的设计中没有得到解决,我会担心,因为他们可能会看到其他模块的其他问题,而不仅仅是FRAM问题。 我强烈建议客户设法消除AVcc启动过程中的这种长时间延迟。

    对于2号:

    您说MPU的实施有所改进,但并未完全解决问题。 您还提到他们手动实施了MPU。 他们能否共享他们的MPU init代码,以及它在程序中的哪个点运行(例如,它是在main()的开头立即调用的,还是从__system_pre_init()调用的?) 或者他们是否使用MPU工具中的手动选择-如果是,他们是否可以共享他们在MPU工具中选择的设置?

    要确认:当您用MPU列出损坏的地址时,您的意思是地址0xF000到0xF58C (而不是0xF0000)吗?

    此致,

    Katie

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

    此问题是否仍然存在? 是否有任何更新?

    此致,
    Katie