主题中讨论的其他器件：TM4C123、 MSP430F5308
您好！
我的焦点客户在 Tiva TM4C123GH 上运行复制器派生代码。 它正在对 MSP 5526进行编程。 它可以在其他微型设备(5308)上工作、但在5526上使用时、它们可以：
1) 1)通过调用 GetDevice_430Xv2 [ JTAGfunc430Xv4.c：922]成功将目标置于 JTAG 控制下
对 ReadMemQuick_430Xv2 [:942]的调用成功，并显示每个目标的正确设备 ID (F5308为0x1381，F5526为0x5526)
2) 2)调用 EraseFLASH_430Xv2 [ JTAGfunc430Xv2.c：1221]、其中 EraseMode 为 ERASE_SGMT、而 EraseAddr 为 Info D 段的起始地址。
这是成功的、并通过调用 EraseCheck_430Xv2 [ JTAGfunc430Xv2.c：1326]来验证。
3) 3)调用 EraseFLASH_430Xv2 [ JTAGfunc430Xv2.c：1221]、其中 EraseMode 为 ERASE_MAIN 、EraseAddr 为代码段的起始地址。 我们已确保将 F5038使用的0xC000代码起始地址更新为 F5526用于 main 第一段的0x4400。
针对 F5308而不是 F5526、这是成功的、如对 EraseCheck_430Xv2 [ JTAGfunc430Xv2.c：1326]的调用所示。
客户写入：
我们还想进一步探讨这一失败、因为我们已经发现了有关这一失败的更多详细信息。 通过查看中间函数调用的返回值、我们开始看到 EraseFLASH_430Xv2调用本身内部的第一个故障提示。 我们注意到的第一件事是、在故障情况下、我们始终会根据超时退出第1239行上的 DO 循环。 即使我们将超时延长了100倍至300、000、也是如此。 第二个原因是对 SyncJtag_AssertPor [：885]的调用失败、因为 IR_Shift 的返回值不是0x91、而应该是该器件的返回值、而是返回0x40或0x28等值。
您是否知道会发生这种情况的任何情况？ Slau320似乎非常坚定地认为 IR_Shift 应始终返回 JTAG ID。
我已要求他们在退出 ERASE_MAIN 后执行 GetDevice 操作、以确保他们没有退出 JTAG 通信。 5528与需要更改的5308有什么根本不同？
