[参考译文] MSPM0G3507：连接到目标时出现 debug/cortex_m0p 错误

尊敬的 Akshay：

根据显示的链接器命令文件和 CCS 闪存设置、这看起来像是在 0x0000A400 处链接和编程的应用程序映像、而不是在正常复位矢量位置 0x00000000 处。

仅当已经在 0x00000000 编程了有效的引导加载程序时、这才没关系。 复位时、Cortex-M0+首先从地址 0x00000000 获取初始栈指针和复位矢量。 如果引导加载程序区域为空白、已擦除或未正确编程、则器件不会自动跳转到位于 0x0000A400 的应用程序。 这可能会导致显示引导/调试诊断消息、包括嵌套异常/无效 CPU 活动/目标连接故障。

在链接器文件中：

BOOTLOADER : origin = 0x00000000, length = 0x0000A000
BOOT_INFO_1: origin = 0x0000A000, length = 0x00000400
APP_1     : origin = 0x0000A400, length = 0x00012000
.intvecs: > 0x0000A400

此外、CCS 闪存设置屏幕截图显示仅正在擦除/编程应用扇区范围、从 0x0000A400 开始。 这意味着 CCS 没有在 0x00000000 处对复位矢量/引导加载程序进行编程。

请检查以下内容：

1. 如果这是独立应用、请使用标准 MSPM0G3507 链接器命令文件并 .intvecs 置于 0x00000000、而不是 0x0000A400。 然后使用正常的主闪存擦除/编程配置。

2. 如果这旨在用作引导加载程序+应用程序工程、则首先将有效的引导加载程序编程到 0x00000000–0x00009FFF 中。 该引导加载程序必须验证应用程序映像、将矢量表设置为位于 0x0000A400 的应用程序矢量表、加载应用程序栈指针、并跳转到应用程序复位处理程序。

3. 您的 APP_1 区域为： 0x0000A400 + 0x00012000 = 0x0001C400 --> 因此、如果您继续按范围使用扇区擦除、请确保擦除范围涵盖整个应用区域。 屏幕截图似乎以 0x0001C000 结束、如果使用该扇区、则可能会使 APP_1 区域的最后一个 1KB 扇区保持未擦除状态。

4. 避免对 NONMAIN / BCR/BSL 配置区域进行编程或擦除、除非您特别打算修改这些区域。 不正确的 NONMAIN 配置可能会禁用调试或以其他方式使恢复变得更加困难。

5. 要恢复器件、请从 CCS/UniFlash 执行 DSSM 批量擦除或恢复出厂设置、对电路板进行下电上电、然后首先加载链接在 0x00000000 处的已知良好 SDK 示例。 正常运行后、重新添加引导加载程序/应用程序偏移流。

因此、可能的根本原因不是堆栈大小或 MSPM0G3507 器件本身。 问题是应用程序链接在 0x0000A400、但复位后、器件仍需要在 0x00000000 处提供有效的可执行启动代码。 希望这对您有所帮助！

-布赖恩