[参考译文] MSPM0G3519：构建 GPIO_TOGGLE_OUTPUT 代码时出错

嗨、您能告诉我您是否更改了任何工程选项吗？ 我之前肯定见过这种情况、但这可能是由于多个问题造成的。 您能否尝试导入工程的新副本并查看问题是否仍然存在？ 这通常是由于链接器/启动文件中的一些更改或器件选择所致、您能否确认目标器件与 SysConfig 中的内容匹配、确保没有重复的启动/链接器文件？

-布赖恩

您好、

我尝试了一个新的副本,即使我保留了我的工作代码的备份,两个都不工作. 即使我用 syscfg 导入了一个空项目,该项目也不会构建。 我不能在哪里找到问题。 而当辅助 BSL 和 BSL 软件调用等其他代码时、这些代码也正常工作。

请帮帮我

谢谢、

但为什么会这样发生,有什么原因?

subdir_rules.mk 由（我想）SysConfig 生成。 我不知道什么会触发（重新）生成、也不知道为什么会错误地（重新）生成。

您好、

现在在每个项目中,我得到了相同的错误,在这个项目中添加文件后,现在在给定的路径中文件不存在。

它会对固件升级产生影响。 我是指如果我从 CCS 刷写代码时生成的.bin 文件、它可以正常运行、但如果我执行 fimrware 升级、它就不能运行。 是否有这种影响？  

我有一些较早的.bin 文件的大小为 2432 字节、在固件升级时运行良好、但现在我生成了一个 3044 字节的文件、当我进行固件升级时、它没有运行。 原因可能是什么？ 与此相关的是、我在另一个问题上提出了一个问题、但却不能回答。 你能原谅我吗?

我将等待您的答复。

谢谢

1) 此权变措施的一个风险是它可以有效地锁定您特定的 MSPM0 型号。 您只提到使用一个变体 (G3519)、因此我预计这不是您看到的。

2) 构建为在固件升级中使用的程序通常使用非标准链接器 (.cmd ) 文件。 似乎导致此（假定）SysConfig 故障的原因也可能导致您的工程“忘记“您的备用链接器文件。 我想我还没有遇到这种情况、因为我几乎总是使用标准模式。

我怀疑实际的修复程序必须位于 SysConfig 中、我无法提供帮助。

您好、

我完全卸载并安装了 IDE 和 SDK ,现在它可以正常工作。 但您能建议一些关于固件升级的建议、为什么这个 3020 字节的文件无法正常工作。

关于  3020 字节文件的固件升级失败、此特定大小通常是 协议不匹配 或 闪存对齐 问题的症状、而不是文件本身的内容。 您可能会看到此情况的几个原因：

• MSPM0 引导加载程序 (BSL) 有一个严格的计时器。 如果您的文件很小、但以非常低的波特率发送、或者如果数据包之间存在长延迟、BSL 可能会  在传输完成之前超时。
• 标头和 CRC 不匹配
• 闪存扇区对齐
• 非主存储器锁定
• 存储体交换要求

您能否检查 更新日志 或  更新工具的控制台输出？ 如果知道它在“开始“、“数据传输“或“验证/交换“阶段是否失败、我相信会找出确切的原因。

-布赖恩