主题中讨论的其他器件： TM4C123GH6PM、EK-TM4C1294XL 、TM4C1294NCPDT
您好、我们使用 TM4c 板已有几年了、这个问题似乎主要出现在 TM4C129ENCPDT 板上。
问题：我们有一个 Windows 应用程序使用 dfuprog.exe (由 TivaWare_C_Series-2.2.0.295提供)、在某些计算机上、相同的 bin 文件会使其更新失败(DFU 错误-7)、而在其他计算机中、它使用相同的 bin 文件和相同的电路板可以正常运行。 这给我们的客户在需要更新我们的新软件时带来了巨大的问题、同时也给我们的研发带来了问题。
到目前为止我们收集的信息：
在 Tivaware c 系列中修改代码以获得包含有关该问题的详细信息的本地编译后、问题的主要源似乎在 lmdfu.dll 中。
此问题出现在函数中：[LMDFUParamsget]。
在没有出现问题剂量的计算机中。 [DFUDeviceInfoGet]提供的信息似乎与 TM4C129ENCPDT 提供的预期规格相匹配。 这会导致稍后通过大小检查(我们使用 bin 文件、而不是完全 DFU 扭曲的文件)。
在问题发生的计算机中、 尽管该 电路板是 TM4C129ENCPDT 电路板、但我们得到的规格与 TM4C123GH6PM 相匹配。 不清楚为什么会出现这种情况。
问题并不像 ROM 代码返回的值错误那么简单、因为即使在 Windows 端我们使用了应该使用的值、刻录也将不会继续、正如我们观察到的那样、
此问题可能会在 Windows 10和 Windows 11上发生。 我们无法确定哪些因素会造成这种行为的发生。 这种行为也可能突然消失,而 dfuprog 工作如预期。
当计算机有这个问题(大多数发生在 TM4C129ENCPDT ),它似乎也影响 dfuprog 燃烧的 TM4C123GH6PM ,但我们没有进一步研究它。
从我们无法访问 ROM 代码的角度来说、我们无法调查 ROM 为什么突然返回错误的规格。
环境规范：
- 在 Windows 应用程序调用 defuprog 之前，该电路板位于 ROM_UpdateUSB 函数中。 激活的 USB 外设。 在这种状态下时钟速度为50MHz、并且禁用其他中断。
- 问题剂量不会产生在一些计算机,主要是因为我们得到的 spescs 是正确的。 在工作计算机和非工作计算机中、直到规格达到的整个过程都是相同的。
-当我们试图从 ROM 中提供正确的值而不是错误的值时,lmusbdll.dll 出现了错误,就像我们发送的一样, ROM 去匹配本身会导致自己从 DFU 模式退出。
