客户将 CPU2设置为之后转至 main 复位 但它不起作用(对于 CPU1、它可以正常工作)
当他们设置脚本时：scripts->EMU 引导模式 select->EMU_boot_flash 也适用于 CPU2、但在将程序再次重新加载到 CPU 后、它停止工作。
他们如何解决这一问题？
重新启动 选项可以正常工作、但仅在 CCS 级别工作。
通常他们使用 javascript 来运行一些脚本： 复位 工作正常、 重新启动 不起作用、它只是停止了。
尊敬的 Sebastian：
问题是由 CPU2的0xD00寄存器中的值引起的。 电源复位后，该值始终加载为0x**025A。 使用此值、CPU2将始终在等待引导模式下引导、在这种模式下、它将保持空闲状态、等待 CPU1释放它。
当加载程序或使用"重启"按钮时、JTAG 调试探针只会跳转到 CPU1或 CPU2上 main 的位置、因为它知道程序启动的位置。
当您复位器件时、它将返回到引导 ROM。 对于 CPU1、0xD00处的值由引导模式引脚确定、并将在上电时设置。 当您对器件进行软件复位时、它将针对0xD00的最后2个字节中设置的值进行相应引导。 这些选项如下所示。
如果 CPU1已设置为从闪存(0x**0B5A)引导、那么如果您的程序存储在闪存中、它将引导至闪存并转至 main。 如果 CPU1设置为 获得引导模式(0x**035A)，则它将读取 OTP 中的一个位置以确定引导模式。 默认情况下、OTP 中的此位置设置为全部为0xF、并引导至闪存。
由于 CPU2在电源复位后将始终在0xD00处编程0x**025A、因此它将始终等待 CPU1释放它、除非您在0xD00处对值进行重新编程、 EMU_BOOT_FLASH 脚本就是这样做的。
另一种可以使用的权变措施是在 CPU1 c 代码中放入一行、告知 CPU1将 CPU2从复位中拉出、如下所示。
CPU1将卡在这一行、直到它将 CPU2拉出复位。 因此、 在 CPU1和 CPU2均跳转到 main 后、您需要复位 CPU2 (使其处于等待引导状态)、然后可以运行 CPU1和 CPU2程序。
如果您需要进一步澄清其中的任何一个问题、敬请告知。
此致、
Ben Collier
