我的印象是、应该使用基于闪存的 Tivaware 例程启动新的固件项目、然后在代码被验证后才转到 ROM_routines。
我正在编写测试固件、作为产品开发的硬件验证阶段的一部分。 我碰巧开始使用 Tivaware driverlib 中的 MAP_函数、假设闪存的使用在将来会成为一个问题、并且还假设如果 driverlib 未编译到我的映像中、则下载代码的更改应该更快。
我注意到、我的固件似乎随机挂起、但仅使用我添加的新代码。 起初、我查看了所有常见的可疑情况、例如指针和中断、但很快就消除了这些问题。 真正奇怪的是、我将#if out the problem code、and then ove to accessing new peripherals、and then revisit after a revisit men 我能够包含以前有问题的代码、它可以正常工作！ 只有较新的段才会导致问题。 旧代码突然工作而不被重写(只是被逐字添加到之前失败的内容中)这一事实非常令人沮丧。
最后、我决定停止使用 ROM_FFunctions、以便我可以单步进入 driverlib 函数来诊断问题。 为此、我删除了 rom.h include、但保留了 rommap.h include。 因此，我的代码是用 MAP_*编写的，但我假设没有 rom.h，任何 ROM_*函数都不可用。 我完成此操作后、我立即开始处理编译器错误。 我通过为我正在使用的各种外设添加标头来修复这些编译器错误。 这似乎已经消除了神秘的行为。 我还没有通过返回 ROM 来测试东西，但我假设 ROM_*代码现在可以更好地工作，因为我已经包含了所有必要的头文件。
总之、 当通过 map_*宏访问外设以及同时包含 rom.h 和 rommap.h 时，编译器似乎没有抱怨所有缺少的标头-我的抱怨是代码中的随机故障是由我的固件调用 ROM_functions 导致的 没有正确的 C 语言声明、因此可能会错误地向这些函数发送参数、从而导致灾难性故障。
由于这种体验、我建议创建新固件的用户可能应首先关闭 ROM 选项、以确保所有必要的接头都已安装到位。 在编译功能之后、切换到 ROM 库并节省空间应该是安全的。
我是否遗漏了什么？ 我很确定我没有遇到任何构建错误。 如果存在严重的构建错误、Code Composer Studio 通常会拒绝运行我的固件。 在我至少暂时搁置 ROM 之前、我显然会有非常可疑的行为。
欢迎提供意见。
