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.

[参考译文] MSP430FR4133:可纠正的FRAM错误有多严重?

Guru**** 2589275 points
Other Parts Discussed in Thread: MSP430FR4133, MSP-FET

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

https://e2e.ti.com/support/microcontrollers/msp-low-power-microcontrollers-group/msp430/f/msp-low-power-microcontroller-forum/619768/msp430fr4133-how-serious-are-correctable-fram-errors

部件号:MSP430FR4133
主题中讨论的其他部件: MSP-FET

在使用MSP430FR4133开发应用程序后,将生成前16个器件
测试已经开始。 其中一个设备显示可纠正的FRAM错误。 我差不多
忘记了一年多前我为这些错误启用NMI的事实,因为我从未这样做过
在我的两个测试板上体验过它们。
所以我想知道这里看到的这个错误是不是著名的“它只是在A中发生一次
但现在它发生在您身上"错误或它是一个严重的问题。
我没有找到很多关于FRAM错误的真实数据--只是注意了
在温度不合适的情况下焊接设备可能会导致问题。
是的,这是一个可纠正的错误,只有一个,但我不知道我是否担心...

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

    一个可纠正的FRAM错误并不是什么大问题。 如果出现多个错误或重复错误,会引起更多的关注。 我会更加关注与此E2E帖子中所发现的错误类似的不可纠正错误。 e2e.ti.com/.../57.592万

    有关FRAM可靠性的更多信息,请参阅以下应用说明。 它包含有关错误率和潜在降尘(非常低)的更多信息。 http://www.ti.com/lit/slaa526
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好,

    感谢您的回答。 我还以为有时会出现一个可纠正的错误
    不太关心。 将尝试解释整个故事:

    正如我所说,我们制造了16台设备。 它们上使用的固件状况很好,运行正常
    在2种不同的测试设备上运行数月,没有问题。 在这16台设备中,有14台运行
    完美地,有人展示了此单个可纠正错误,而第16个则促使我坚不可当:

    它每天大约重新启动5到10次。 它从整个固件的入口点开始-这是
    中断源"系统重置(0xFFFE)"指向的位置。 没有其他的地方可以说明这一点
    位置,我添加了一些调试计数器,并验证每个计数器都确实受到了攻击
    重新启动。
     
    我编程了一个非常舒适的事后分析代码,它记录了,以及其他数据
    SYSRSTIV寄存器的内容,以便我找出重新启动的原因。 事实证明了这一点
    按下"重置"按钮时,0x0004会留在那里,软件POR会给我0x0014。
    有趣的是,对于所有这些不需要的崩溃的90 % ,SYSRSTIV是0x0000,但调试
    计数器将递增,以便我可以确定它是由0xFFFE的“系统重置”矢量引起的。
    我不理解这一点,因为每次重新启动都应该有一个相应的中断事件,即
    与0x0000不同。
     
    这些不需要的崩溃的另一个10 % 是无法纠正的FRAM位错误,我可以通过看到
    值0x001C留在SYSRSTIV中。

    我之前已经阅读过您的有关FRAM可靠性的PDF,所以目前我唯一的结论就是这一点
    处理器在某处或某种程度上受到影响。 也许焊接不合适
    (太热/太长)或在焊接或其他任何操作之前打开太长时间的密封组件。
     
    也许我应该更换该崩溃设备的CPU,看看它的性能是否更好...
     
    有人有什么想法吗?
     
    谢谢!

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

    如果您有能力进行芯片交换,这可能会为您提供一个有价值的数据点。 另外,您是否有一个在PORT28勘误表的勘误表文本中建议的测试针上的下拉列表? 我可能会看到意外进入JTAG/调试模式导致一些重置。
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    是的,我可以更换芯片。 但是,有关的所有调试选项
    这个问题会消失;-)
     
    愚蠢的问题:我以前读过PORT28,但我想知道,在使用什么东西时是否
    下拉菜单,是否会连续重置,设备将永远不会启动?
    当前,RST_NMI_SBWTDIO连接到接在GND的1 nF电容器,即复位
    切换和(使用短迹线)至TAG-Connect工具的电极。 SFRRPCR是
    处于默认状态(0x001C),因此当前上拉处于活动状态。

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

    下拉列表应放置在TEST/SBWTCK引脚上。 RST/NMI/SBWTCK只能将建议的1nf盖接地。
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    好的,现在我明白了:

    SFRRPCR.SYSRSTRE通常只能控制RST/NMI/SBWTCK的拉电阻。
    但是,由于存在错误,它还控制test/SBWTCK的下拉列表。 因此,PORT28
    建议将SFRRPCR.SYSRSTRE设置为1,以便我们可以确定该测试/SBWTCK
    被拉下来了。 但通过这种方式,我们强制执行RST/NMI/SBWTCK的拉电阻
    也启用,因此必须使用SFRRPCRE.SYSRSTRUP来确保设置此电阻
    以一种不会造成伤害的方式。

    由于我的SFRRPCR处于默认状态(0x001C),我应该对此没有问题。 但是,
    我还会将测试/SBWTCK接地并查看发生的情况。
    稍后再报告,谢谢!
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    Jace H 说:
    下拉列表应放置在测试/SBWTCK引脚上。[/QUOT]

    好的,结果如下:

    首先,我检查了内部下拉列表,结果给出了
    我两个方向大约32公里。
     
    下一步是向GND添加额外的10k电阻器。 没有
    Help (帮助)--几分钟后第一次重新启动。

    然后我尝试将其直接拉至GND。 结果相同。
     
    现在,当你把它拉到Vcc时,野兽就跑过来了
    24小时内不会重新启动。 当然,重置引脚没有
    在此处工作,因为应用Vcc测试可启用中的JTAG
    转动可禁用外部重置功能。

    所以一个解释可能是这个芯片有点混乱
    在内部启动并生成重置,而无需真正的原因。 这个
    也可以解释为什么SYSRSTIV在90 % 的所有案例中为零         
    以及为什么在15+2其他设备上看不到此行为。
    通过启用测试重置功能(包括错误
    部件)被禁用。                  

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

    Jace邀请我参加这个主题。
    您是在ESD安全环境中使用这些部件,还是在没有ESD保护的情况下在办公桌上使用它们。
    在SYSRSTIV中显示重置但没有值(0x0000)的第16个设备很奇怪。 如果您拔出测试引脚并启用JTAG模式,则更像是损坏。
    您能帮我一个忙并测量此器件的LPM4电流,所有端口输出低电平和高电平,以查看我们是否可以识别此部件上的泄漏?

    不确定是否已被询问,但我认为您根据您的工作频率设置了等待状态,以确保您的操作符合规格?
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    Tom,
    Jace邀请我参加这个主题。
    [/引述]
    欢迎;-)

    [引述]
    您是在ESD安全环境中使用这些部件,还是在没有ESD保护的情况下在办公桌上使用它们。
    [/引述]
    对我来说,我可以说"是",对制造商来说,我也可以说(他们
    已制造并仍在使用制造此设备的前代产品
    MSP430P325A (适用于Aages)。
     
    [引述]
    在SYSRSTIV中显示重置但没有值(0x0000)的第16个设备很奇怪。 如果您拔出测试针脚和e,则更像是损坏了
    nable JTAG模式。
    [/引述]
    但在启用但未使用JTAG的情况下仍运行的行为是否正常?
    此外,我始终使用JTAG (确切地说是SBW)通过上载软件
    此设备上的MSP-FET和MSPFlasher ...
     
    [引述]
    您能帮我一个忙并测量此器件的LPM4电流,所有端口输出低电平和高电平,以查看我们是否可以识别此部件上的泄漏?
    [/引述]
    这很难:几乎所有端口都在使用中。 应该可以是静态低电平
    (必须检查)但静态高将产生不良影响,从而产生任何影响
    当前测量值无效。
    但我可以说,到目前为止,该软件一直到LPM3。 的常用电流
    整体(!) 在这种情况下,系统大约为3 uA (LCD,RTC,...) 。 这是测量的
    使用Keithley 2k DMM。 此电流在15+2其他设备和上正确
    这也是一个问题。

    如果我们决定将整个部件从PCB上剥离,我可以切割所有引脚
    除了电源,xtal,SBW,...,然后尝试LPM4测量。

     
    [引述]
    不确定是否已被询问,但我认为您根据您的工作频率设置了等待状态,以确保您的操作符合规格?
    [/引述]
    我用NWAITS_1运行16MHz。 但这让我想到了尝试慢一点的想法,
    只是看看它是否有用...

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

    谢谢
    -您在ESD安全环境中操作
    -您的LPM3电流表明泄漏意味着似乎没有严重损坏(我认为此处不需要所有GPIO输出均为低电平的LPM4)
    -16MHz,NWAITS_1符合规范,但请尝试较慢速度排除此项

    是的,只要不将序列应用到JTAG引脚,启用JTAG就不需要停止器件。 那么,在执行此操作时,JTAG引脚是否已端接?

    我是否理解您仍然可以重现该行为并能够解决该问题?

    我想到的另一件事是堆栈违规。 是否确定固件或数据管理不会损坏堆栈?
    是否还可以在连接调试器的情况下重现该行为?
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    Tom,

    这至少是一种奇怪的现象。 我认为您应该运行另外两个测试。
    1)将重置设置为NMI功能,并查看是否发生相同的重置。
    2)执行A-B-A芯片交换。这意味着用已知良好的芯片替换当前行为不正常的设备,并将行为不正常的设备放置在已知良好的主板上。 我们从这里观察问题出在芯片还是主板上。
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    Tom,
    谢谢
    -您在ESD安全环境中操作
    -您的LPM3电流表明泄漏意味着似乎没有严重损坏(我认为此处不需要所有GPIO输出均为低电平的LPM4)
    -16MHz,NWAITS_1符合规范,但请尝试较慢速度排除此项
    [/引述]
    上到NWAITS_7 --仍在重置。 目前我正在运行它
    使用8 MHz时,它尚未重置。 但这并不意味着什么
    它只运行了18分钟。 必须等到明天……

    [引述]
    是的,只要不将序列应用到JTAG引脚,启用JTAG就不需要停止器件。 JTAG引脚也是如此
    当您执行此操作时?
    [/引述]
    我不使用的所有引脚(仅4个)都被从内部拉下。
    复位引脚可以看到典型的1nF,而不会看到其他任何内容。

    [引述]
    我是否理解您仍然可以重现该行为并能够解决该问题?
    [/引述]
    为了再现它,我必须:
    -保持TEST/SBWTCK打开(内部下拉)或接地
    等待。 有时2分钟,有时2小时。 两者之间。

    除了拉测试/SBWTCK高外,我没有其他解决方法!

    [引述]
    我想到的另一件事是堆栈违规。 是否确定固件或数据管理不会损坏堆栈?
    [/引述]
    我有17台设备运行正常。 一周,然后
    另一个月。 软件都是汇编程序,没有库,没有外来的
    代码,没有奇怪的编译器错误。 我不需要太多堆栈,因为我不需要
    Pushs和pop。 只是一些函数调用和中断。 我有一个堆栈
    防护装置位于底部(下面仍有未使用的RAM)
    它从未被覆盖。

    [引述]
    是否还可以在连接调试器的情况下重现该行为?
    [/引述]
    我没有调试器,只有一个仅用于上传的MSP-FET
    和使用MSPFlasher下载。 当前,设备在未连接的情况下运行
    但我可以在连接MSP-FET的情况下重试(当然不执行任何操作)。

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    我将在明天尝试1)(或在8 MHz测试失败后;-))

    关于2):我可以更换芯片,但我怀疑目前的行为不正确
    一个人将生存下去。 我假设只要更换主板,主板就会正常工作。
    它没有花哨的设计--两层(底部几乎完全接地),一些0805部件,一些
    SOT-23,24LC512,用于USB和LCD的FTDI。 易于在光学和电气方面进行检查
    和其他15个(良好)设备一起制造...
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    Tom,Jace,

    感谢所有的意见,根据我们迄今为止收集的信息,我现在还不知道是什么导致了这些重置。

    A-B-A交换是危险的,因为它可以通过焊接热来消除影响,因此我投票将此作为最后的选择。

    假设它与memroy有关,因为在8 MHz和nWait_7中 它似乎工作正常,我们应该也可以通过连接的调试器看到它,也许可以识别它发生的位置。

    Tom,

    当您拥有FET时,您已经拥有HW,您是否还拥有完整的项目以及IAR或CCS的源代码,以便让它在IDE中运行以设置断点并调试项目。 通过这样做,我们或许能够收集更多信息。

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

    [报价用户="Dietmar Walther"]
    A-B-A交换是危险的,因为它可以通过焊接热来消除影响,因此我投票将此作为最后的选择。
    [/引述]
    是的,仅当所有其他选项都已删除时才会执行此操作

    [引述]
    假设它与memroy有关,因为在8 MHz和nWait_7中它似乎工作正常,我们应该能够通过连接AS的调试器看到这一点
     也许可以确定发生这种情况的位置。
    [/引述]

    等待,只是要明确:nWait_7测试是在16 MHz下完成的,但失败了!
    尚未完成8 MHz测试(不等待)。
    事实上,今天早上它已经运行了9个小时--有些东西
    我从未见过16 MHz的。 我没有触碰它,我们会看到它会有什么
    发生在今天下午晚些时候。 如果它能在8 MHz下继续工作,我会
    再次切换回16,查看重新启动是否会恢复(可能会恢复
    但最好是确定)。

    此外,测试重置配置为导致NMI时发生的情况       
    也必须要做……
     
    [引述]
    当您拥有FET时,您已经拥有HW,您是否还拥有完整的项目和IAR或CCS的源代码,以便让它在中运行
    IDE设置断点并调试项目。 通过这样做,我们或许能够收集更多信息。
    [/引述]
    从未接触过IAR或CCS --我正在使用CPP,气体(和其他
    binutils)和带有MSPFlasher的src_cat。 IAR或CCS不会在我的上运行
    平台。

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

    时钟为8 MHz (无等待状态)时,系统运行26小时(无)
    重置。 然后,我切换回16 MHz (一个等待状态)并进行首次重置
    几分钟后来的。
     
    我不知道什么可能是错误的。 电源应该正常:一个1uF
    位于远离芯片的5 mm 上,接下来是10 UF和TPS7.8233万DDC
    调节器。 VCC有短轨迹和粗轨迹,GND仍然是GND平面。
    该芯片不必驱动很多:一个LCD,一个24LC512 EEPROM,几个
    MOSFET,仅此而已。 我还通过快速示波器检查了3.3 电压
    --没有故障或噪音,只是一条平坦的线。

    启用16 MHz时,将从TLV值和加载DCO
    降低9位CSCTL0在164和165之间跳转。 这不是完美的,但还可以。

    如果时间允许,我明天将使用NMI功能,也将启用
    DCOFTRIMEN并将DCOFTRIM设置为4 (这使CSCTL0更接近256)
    看看这里是否发生了变化...

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

    我越来越接近了。 首先了解一些需要了解的详细信息
    发生什么事了:

    该设备使用USB总线供电的FTDI USB<->RS232转换器进行传输
    数据传输到PC。 我注意到这些假复位不会发生,当
    USB已连接(正常操作时未连接)。

    在正常操作过程中,设备进入LPM3并由唤醒
    RTC ISR,每500毫秒。 它为10-100我们做了一些工作,然后它又回来了
    至LPM3。

    但是,FTDI用于其接口逻辑的3.3 电压也会被馈入
    MSP的端口引脚。 这样MSP就可以检测用户是否
    已连接USB端口并执行一些适当的操作。

    我使用的是高波特率,这使得有必要为使用SMCLK
    UART。 因此,在使用USB端口时,我们必须处理的任务之一是
    是为了防止设备进入LPM3 - RTC ISR如下所示:

    RTC_中断:
     做些事情
     如果PC_已连接,则
       准备LPM0
     否则
       准备LPM3
     FI
     印度

    这样,只要PC有,UART就可以使用其高波特率
    已连接。

    当我注意到这些虚假复位在USB一出现就消失了时
    连接后,我断开了FTDI与MSP之间的所有线路,以查看是什么
    发生。 我一拔出上面提到的3.3 电压
    USB存在线,设备在几分钟后开始再次重置
    即使USB端口已连接。

    当然,其逻辑结果是为MSP提供自己的设备
    此端口引脚上的3.3V电压(因此它假定USB端口已连接并阻止
    从进入LPM3)。 现在,它运行数小时而无需重置(在的LPM0中)
    课程)。

    因此,我们可以假设此设备正在发生某种情况(但不是
    17其他)。 现在我只需要弄清楚...

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

    Tom,您好!

    您取得了进步,这很好,但我认为我必须更详细地思考您所说的话,但这会引发更多问题:
    1.设备的供电方式?

    2.您是否可以拆除主电源(DVCC),但仍为任何GPIO引脚提供另一种电压? 这样,您将通过不允许的ESD导轨后门为设备供电。

    此致,
    Dietmar

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

    1.设备的供电方式?[/QUOT]

    VCC良好且稳定(专用tps7.8233万,靠近台钳和
    足够电容器)。

    [报价]2.您是否可以拆除主电源(DVCC),但仍为任何GPIO引脚提供另一个电压? 这样,您将通过不允许的ESD导轨后门为设备供电。[/QUOT]

    我最初是朝着同一个方向思考的(假设这一点)
    非常芯片在配电和获得时损坏
    通过受影响区域的某些端口引脚提供)。 但自从我开始
    将ISR末端跳到LPM3更改为仅交换
    在LPM0中,即使没有USB也可以工作(因为这与它相同
    本可以使用USB完成)。

    考虑到8 MHz工作,16 MHz只有在我们不工作时才工作
    进入LPM3让我觉得FLL / DCO可能会疯狂
    这种芯片正在缓慢偏离规格,因此它确实如此
    这些有趣的事情(如不使用矢量重置或偶尔重置)
    输出FRAM错误)。

    这可能是由于我的使用模式:

    CPU始终处于LPM3状态。 RTC ISR每500毫秒唤醒一次
    它。 它所要做的任务通常很短:介于之间
    1和4个ACLK周期(介于30和120 us之间)。
     
    在这些时间内,它当前配置为打开FLL。
    但是,我在其他帖子中看到,CPU在其中
    FLL需要更长的时间来正确地稳定DCO
    不知道这一次,它是坚不可当的。
     
    如果没有人这样做的话,我可能必须尝试朝这个方向发展
    一个更好的主意...  

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

    好的,你知道了,所以用钟表来测量它们,你能用关键的角度来测量它们,并提供示波器镜头吗?
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    嗯,我已经在玩这个主意了。 幸运的是,WFP 8.0 是免费的,所以我可以在这里启用SMCLK。
    OTOH,有时需要一个小时才能崩溃,所以我不得不坐一个小时盯着
    查看发生的情况的范围;-)。 那么,我可以尝试检查跟踪缓冲区是否足够大
    捕获SMCLK足够长的时间,因此我将其置于某个预触发模式,实际获得
    点击设备的重置,然后向后滚动以查看发生了什么...

    我目前的方法是完全出于测试目的而禁用FLL稳定,比如
    只要我不改变Vcc (这不会发生)或温度,这就不会有什么影响。
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    是的,你是对的,但是你可以使用脉冲宽度触发器,在你实际时钟时触发更低的脉冲,让它运行。
    我的意思是假设时钟会造成这种情况,因为我期望它会变得很快。 但可能是您必须运行它两次触发高脉冲和低脉冲(峰值)。

    但当然您也可以禁用FLL,但观看时钟让您更有信心时钟信号看起来干净。

    另一件事是,您可以在设备停止时,在所有电源模式更改为跟踪范围之前实现端口切换。 这可能有助于我们更好地了解何时发生。
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    是否触发脉宽? 想知道如何教我1988年的古人做这个;-)
    不,认真地说,您是对的。 如果其他一切都失败了,我会得到一个更现代的范围。

    但首先,我会尝试与FLL比赛。 你不会偶然知道影响
    中提到的

    e2e.ti.com/.../7.489万

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

    Tom,您好!

    我认为线程与它无关,因为如果时钟停止,您将不会得到重置,如果您通过WDT获得,在这种情况下,SYSRSTIV会指示它。 这是我的看法。

    FLL本身只是将DCO步进与FR4133具有 不同的DCO体系结构和更好的分辨率相结合。

    再次检查具有高分辨率范围的时钟是最好的。 如果您可以用2个示波器跟踪时钟,而一个示波器在高峰值上触发,而电阻器在低峰值上触发,则更好! 如果作用域不触发,我会期望什么也没有。

    另一个想法是以动态方式测量电流,以查看是否存在指示重置的跌落或峰值,也许这也会给我们一些很好的结论。

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

    我认为该线程与它无关,因为如果时钟停止,您将不会得到重置,如果在这种情况下通过WDT获得,则SYSRSTIV会指示该线程。 这是我的看法。[/QUOT]

    我复制了错误的链接,我要说的是:

    所以我开始监控CSCTL0,它一直保持不变
    这意味着FLL不调整DCO。 但是,它确实如此
    不会像在提到的主题中那样跑掉...

    因此,在我非常短的活动任务期间,完全实现了FLL
    毫无用处。 但请参阅以下内容:

    FLL本身仅将DCO步骤与FR4133具有 不同的DCO体系结构和更好的分辨率相结合。[/QUOT]

    是的。 我修改了代码,每10到20秒就有一个RTC
    ISR呼叫在LPM0状态下花费了1.5 毫秒-给出足够的FLL
    调整DCO的时间。 现在我可以看到CSCTL0的MOD位
    每次当DCO位在0x165处时更改
    时间,有时为0x164。 TLV值为0x161,因此不会太坏。

    但是,野兽仍然重置;-(.

    [引用]再次检查具有高分辨率范围的时钟将是最佳选择。 如果您可以用2个示波器跟踪时钟,而一个示波器在高峰值上触发,而电阻器在低峰值上触发,则更好! 如果范围没有触发,我希望没有任何内容。[/QUOT]

    我明天会尝试...

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

    事情开始变得有趣...

    我承诺尝试的一件事是测试如果我们将RST引脚配置为NMI,设备将如何反应。
    因此,我将相应的代码添加到设备的初始化序列中:

    之二 #SYSNMIIES,&SFRRPCR
    之二 #SYSNMI,&SFRRPCR
    之二 #NMIIE,&SFRIE1
    

    并通过按下重置按钮并检查SYSUNIV中是否出现0x02来测试它。 确实如此。
    它运行了32个小时,没有重新启动,直到我停止它。

    所以我想我们可以有把握地假设我关于DCO慢跑的理论最终可以接受
    死亡。 为什么这取决于RST引脚的配置方式?

    但它变得更加荒谬:

    我又从RST开始做NMI。 几个小时后,我决定在飞行中改变这个。
    这是可能的,因为我在代码中嵌入了一个小显示器。 所以我启动了显示器
    并翻转0x104中的位0,使RST引脚再次作为复位。 但设备没有
    重置...

    所以我在上面的3行后面添加了“BIC #SYSNMI,&SFRRPC”,启动它,然后再启动它
    10分钟内重置...

    不知道这里发生了什么。 也许它必须至少掉入LPM3一次,直到我可以恢复
    RST引脚用于实际执行重置。 它当前在此模式下运行,但具有#SYSNMI
    由监护仪手动清除(这意味着多个LP3.3),以查看它是否在期间重新启动
    晚上,但我有疑问……

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

    设备在12小时后仍在运行。 我认为这片芯片只是坚果。 不知道是什么
    碰巧遇到了——可能是ESD问题(不要这么认为),也许焊接过热(不要
    想想吧),或者它从工厂里被破坏了……

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

    Tom,

    对于这种情况,真正告诉我的是,将RST线路切换为NMI会停止复位。 这告诉我重置线路上的某种不稳定导致了问题。 我回到了线程中,我只是想澄清一下连接到RST线的电路。 您在该引脚上有一个1nF接地盖和一个47k上拉至VCC,正确吗?

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

    Tom,

    了解这一正确的方法。 您是否将RST引脚功能更改为NMI并在看到重置正确后将其切换回?

    然后您又开始将其设置为RST函数,现在它工作了10个小时? 意味着故障消失了?

    您是否在ESD安全环境中工作?

    此致,

    Dietmar

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

    关于这种情况,真正告诉我的是,将RST线路切换到NMI会停止复位。 这说明重置行上的某种不稳定导致了问题。

    如果重置行的(外部部分)存在一些不稳定,为什么不会出现这种情况
    当它被配置为NMI时? 为什么只有16 MHz而不是8 MHz? 如果我不这样做,为什么不呢
    不要下拉至LPM3 (而是留在LPM0)?

    [引述]我要回顾这条线程,我只想澄清与RST线相连的电路。 此引脚上有一个1nF接地盖以及一个47k上拉至VCC的插针,正确吗?[/QUOT]

    接地时为1 nF C。 我没有外部上拉菜单,但我没有修改SYSRSTRE和
    SYSRSTUP,则启用内部上拉。

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

    [QUETE USER="Dietmar Walther]了解此正确信息。 您将RST引脚功能更改为NMI,并在看到重置正确后将其切换回?[/QUOT]

    对。 但只有在使用内部显示器手动切换回时(这需要几个
    秒:连接USB电缆,键入按键以调用监视器,切换SYSNMI,
    断开电缆)。 如果我在初始化过程中执行此操作,只需几个汇编程序即可  
    命令在代码将其更改为NMI后,它将不起作用。

    然后您又开始将其设置为RST函数,现在它工作了10个小时? 意味着故障消失了?[/QUOT]

    不,我可能对自己说得不好:只有在"几个
    秒后"。 不知道是"几秒钟"还是至少是"几秒钟"
    在LPM3 (500ms后隐含)或任何其他位置。 我将对此进行变通
    有点,但我总是要等几个小时才能确定,这需要一些时间...

    顺便说一下,您在ESD安全环境中工作吗?

    我会这样说,是的。 我不知道在制造过程中发生了什么
    设备。 这是一个专业的企业,但是,没有人知道可能会发生什么
    这是一个很好的芯片。 也许我只是在浪费时间
    炸薯条

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    为了完整起见:该设备使用SYSNMI位运行了23个多小时
    从监视器内手动清除。 我现在按下了重置按钮,它重新启动了(当然)。
    我检查了日志(每次重新启动都会记录重新启动的原因),这确实是一个重置事件
    (SYSRSTIV中为0x04)且无NMI。

    现在,我将继续尝试找出我必须清除SYSNMI的确切位置...
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    下面是最后的结果:我可以阻止设备重新启动
    如果我将以下3个命令放入初始化部分:

    之二 #SYSNMIIES,&SFRRPCR
    bis #SYSNMI,&SFRRPCR
    bis #NMIIE,&SFRIE1
    

    这会将RST引脚切换为NMI功能。 我可以恢复
    通过推杆

    BIC #SYSNMI,&SFRRPCR
    

    RTC ISR (每隔0.5 秒调用一次)和
    设备仍将运行而不重新启动。 如果我将"BIC..."放入
    初始化代码(即,它将在3.
    CMDS (从上开始)重新启动。
     
    我真的需要从上面的所有3厘米。 我一省略了厘米
    修改SYSNMIIES或NMIIE的操作不起作用。
     
    我现在正处于一个我认为可以安全地声称这种芯片的阶段
    只是有一个缺陷...

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

    Tom,您好!

    我非常感谢您在这种情况下所做的所有测试和调试。

    它仍然只有一个部分显示了这一权利。 所有其他人都运行正常吗?

    因此,我认为我们将离线处理此问题,并与您联系,讨论进一步的行动。

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

    [QUETE USER="Dietmar Walther]它仍然只有一个部分显示此权限。 所有其他产品运行正确吗?[/QUOT]

    对。

    因此,我认为我们将脱机联系您,讨论进一步的行动。

    在1.10 之前,我会一直在度假。 也许我会继续,或者由同事接管(或两者兼有)。

    感谢!

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    请注意,我们决定更换CPU,现在设备运行24小时,没有任何问题...
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    感谢更新Tom。 在我看来,问题可能是针对该特定芯片的ESD事件。 如果再次发生,请告知我们。 如果您已准备好,我们可以尝试通过将有问题的芯片放入已知良好的主板来确认此问题,并查看问题是否仍然存在。 现在,我要关闭此帖子,因为问题已通过更换芯片解决。 感谢您的帮助和耐心。
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    Jace H 说:
    ...我们可以尝试通过将有问题的芯片放入已知良好的主板来确认此问题,并查看问题是否仍然存在。[/QUOT]

    嗯,芯片没有存活下来,因为我不得不切断支腿才能将其去除。

    感谢迄今为止的帮助--我也认为这个芯片是坏的……