[参考译文] MSP430-GCC-opensource：CRT .bss 初始化期间看门狗超时

分发中包含一个文件，该文件描述了要执行的操作：./ti/gcc/examples/watchdog.txt

抱歉。 这是一个 RTFM 肯定会有所帮助的问题，尽管我仍然认为应用程序编写人员在进入 main()之前不需要担心看门狗。 因此、我仍然认为 CRT 应该定期复位看门狗、例如在每30000 MCLK 之间

没问题。

在 CRT 库中输入禁用看门狗的代码存在一些技术限制。

器件之间的看门狗地址可能会有所不同、因此该命令不能硬编码到所有 MSP430器件共享的库中。 我们不希望一开始包含许多不同的目标特定版本的 CRT 库来解决此问题。

我们也无法使用将由链接器解析的符号、因为用户可能不会使用 TI 提供的 MSP430-GCC 链接器脚本。

创新的解决方案可能可以解决这些问题、但并不是优先考虑的问题。

很不幸、因为这是一个常见的问题、但这就是为什么它现在在最新版本的用户指南中明确记录了它的原因。

此致、

[引用 user="Jozef_Lawrynowicz"]我们也无法使用链接器解析的符号，因为用户可能不会使用 TI 提供的 MSP430-GCC 链接器脚本。

这是足够公平的。

CRT 是否已经对链接器脚本做出假设？ 例如、需要用户定义的链接器脚本来定义诸如"_stack"等符号 就个人而言、我尝试将工具链提供的链接器脚本视为不可更改的脚本、在覆盖这些脚本时、我确实使用 GNU 链接器脚本的"include"指令将其包括在内。

[引用 user="Jozef_Lawrynowicz"]在输入代码以禁用 CRT 库中的看门狗方面存在一些技术限制。

我认为像这里经常建议的那样、完全禁用看门狗是有害的。 它应该继续运行、并且只能由启动软件定期复位。 这样、如果 CRT 初始化期间的干扰导致 MSP 处于未定义状态、则恢复的机会会更好。 正如我已经说过的，当用户无法修改 memcpy()时，他可以增加看门狗超时，但设备仍会恢复。

几个月前、RTFM 不会提供帮助、因为这是该手册的第一个修订版、其中包含了这些信息。 逾期未交的加法。