C2K 团队、家人和朋友；
我们的客户在下面有一个非常详细的请求、这是为了更好地了解 C2000 WDT。 任何评论都一定会受到欢迎！
摘要如下：
-一般而言，此处的培训模块很有帮助：
但是，我们可能会寻找更多的文档
-对于 XRS 引脚上的简单 RC 可能感觉不是很舒服。 需要审查和提出建议。
感谢我们团队的任何指导。
----
客户提供；
C2000上的看门狗行为：
目标：我希望在使用 RAM 字交换某些状态信息的同时、从引导加载程序切换到应用程序(反之亦然)。
解决方案第1部分：
- 定义 RAM 字(将其称为"App_Vs_Boot_Info")；
- 在运行应用程序时，看门狗以52ms 的持续时间启用；
－ 在运行引导加载程序时，禁用看门狗；
- 在这两种情况下、看门狗被配置为复位器件、而将0写入 WDCR 被用来复位软件；
- 要从应用程序转至引导加载程序、请写入"App_Vs_Boot_Info"、然后强制执行看门狗复位(不是跳转至引导加载程序开始会导致我希望将外设恢复为其复位状态)；
- 要从引导加载程序转到应用程序、请写入"App_Vs_Boot_Info"、然后跳转到应用程序启动；
到 目前为止，一切都按预期工作。 我们提供了几个类似的单元(大约100K...)；
- 但有一个可能出现的情况、"App_Vs_Boot_Info"与预期不符。 (可能是因为我们从未复制过、但确定了它是如何发生的)因此、该单元将卡在引导加载程序中、这并不是很糟糕、因为我们可以对其进行重新编程、看起来加电复位可能会正常恢复；
解决方案第2部分：
-... 问题是、在上电复位时"App_Vs_Boot_Info"可能包含垃圾、因为 RAM 从未上电状态变为通电状态、所以我想知道我们是上电还是看门狗复位...；
-...启动引导加载程序时、"App_Vs_Boot_Info"仅在 WDFLAG = 1时才是可靠的信息(即在看门狗复位之后、否则这是上电复位、"App_Vs_Boot_Info"包含垃圾信息)；
所以 我在上电时添加了这个检查；
- 这在几个器件(同时配备 TMS320F28035和034)上似乎可以正常工作。 然后、我们使用"034"构建了40个单元、这些单元的运行方式与 WDFLAG 类似、但在我预期的情况下、未设置。 因此、该单元将卡在应用程序中、如果我们要重新刷写它、这会变得很糟糕、这是我们在每个单元上的 prod 行末尾所做的事情。 该单元不能提供 JTAG 访问权限(添加到所学的课程... 再次...)；
解决方案器件#3：
- 删除解决方案第2部分，直到我们解决此问题。 这意味着我们可能会在现场遇到随机问题(启动时卡住的单元)、希望没有那么多；
我的理解与问题...：
- 我很难确保在我们的应用中正确使用 XRS 与看门狗与 WDFLAG：令人困惑的文档(或者让我们说个人无法自信地解释它... ;-)；
- 我让看门狗从内部时钟计时、因此通常为10MHz；
- 当执行看门狗复位时、如果我查看 XRS 引脚、我应该会看到一个51us 低脉冲(51.2us = 512/10MHz)->这种情况；
- 在 XRS 引脚上、我们有一个时间常数为220us 的 RC (2.2k Ω 时为100nF)、这足够快、可以在420us 内看到 XRS 上升超过2.5V；
- 从 SPRUGL8C 文档第61-62页中、当 XRS 变为低电平时、WDFLAG 应为0。 当 WDRST 变为高电平时、如果 XRS 为1、则 WDFLAG 应变为1。 由于 XRS 在等于512个时钟周期(由于 WDRST 持续时间)+ RC 产生的持续时间内变为低电平、因此当 WDRST 变为高电平时、XRS 应始终为0、因此在看门狗复位后、不应将 WDFLAG 视为1。
- 还有一个"同步后和8192 SYSCLOCKOUT 周期延迟"条件、但我不确定如何应用；
- 要检查这一点、在引导加载程序的开头、我启用 GPIO 作为输出并将其切换、直到我看到 WDFLAG 为1 (或最大900个循环、即大约13ms)、并在 GPIO 上报告 WDFLAG (JTAG 不用于执行此操作)。 我注意到的是、在 XRS 引脚变为低电平(由于看门狗复位)后、引导加载程序启动975us、并且在我第四次读取 WDFLAG 时(即在 XRS 引脚变为低电平后1ms)读取为1。 然后、我有点困惑。 我找不到关于我所看到的内容的解释。 在复位1ms 后、设置 WDFLAG 的 XRS 引脚采样看起来是一样的；
- 如果我参考" http://secure-web.cisco.com/1WpVOAxyatWQwACpr0wgTXTIiPqtsQi5l95nkg1N5afT2bAcfKT1MoVpx0DrhXOi5r0aj6gWi1MvVgYMAKQ9F9lpXv2gz6TCN5hduKwOzUx7hBiGq4wQedKB1kAeyZEUhlfAjIIoHz2ZPfgREbBY4fgFCDPFEpWxlzxQ6GFjQHSOKjUeaji0luyc2XAJFrJEWDLNubw72eEoa_nz_Fuj1jHQ8V1W5Zzy2Lhlaum_BNdoeymlU5wR8xHS6_wCwldoHAn7CGpdZc9xpCmILHaVedQ/http%3A%2F%2Fprocessors.wiki.ti.com%2Findex.php%2FWDFlag_on_Piccolo"、在看门狗复位时、在 XRS 变为低电平后、WDFLAG 应设置为3.3ms。 不适合我看到的内容。 我们应该对 XRS 变为低电平的8192+512个时钟周期进行计数、这将使我们距离我看到的不远、但不完全是；
然后 ，这个 wiki 还告诉我，如果我想使用 WDFLAG 的话，一个简单的 RC (就像我们使用的 RC)不是一个好主意 (...是的，似乎我们现在已经被指责了... )；
- 似乎我们应该使用 TLV803S 或类似的替换器件、因为 CPU 无法识别上电复位、因为在对其进行采样时、它将始终看到 XRS 线路设置为1；
那么、让我们尝试一下... 如果我执行上电复位... ；
- 我看到 XRS 线路从0上升到接近2V、然后在0us 时变为低电平、发布时间为630us (类似于文档 SPRS584K 第33页的 XRS 脉冲持续时间或典型值为600us 的脉冲持续时间、 或第27页400至800us 范围内的监控器复位释放延迟)，900us 时为2V，引导加载程序在1.55ms 时启动，在14.67ms 时 WDFLAG 仍然不为1；
-... 嗯…… 它似乎检测到上电复位并区分看门狗复位...；
... 这很好，作为一种解决方案还可以，但因为它确实符合我对文档的理解，所以我很不习惯使用它；
我的问题是：
－ 在我对该看门狗的理解中，什么是缺失或错误的？
－ 是否有一份明确/简单/正式的文件能更好地描述这一点？ (我还看 了 https://secure-web.cisco.com/1gMDhxAQph3uDs7BGidjMZXQIcCq_dGgK10qSKt3WST8rEzFraNKuyEuayPaY_MVnOQIY0m4N7E9zyJHmkL0WeI_F4CkJJxw9km6squFphzwejXaA4-O9Aol1NzmOcrqxqq65abo4rnJQXpegUBUWGLZt7cXDByRJYNHPv9kD7Iza9SUmFKcY36yG9BMascgxOAVG6YE-n-pBldFXL0oDYVv8Qt-ri7QVdK0gK9kPkRiUws6WjQ1xwQZo09UtX0pxw3sDzYv72ntniu42Ym38lw/https%3A%2F%2Fe2e.ti.com%2Fsupport%2Fmicrocontrollers%2Fc2000%2Ff%2F171%2Ft%2F419598、也说不清楚...)
- 我们是否可以在 XRS 引脚上使用简单的 RC？
— —有什么建议/提示/建议？
----
