This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
工具与软件:
您好!
我正在使用 DevBoot 模式、一个多核项目在锁步中使用 R5_0、在双核模式中使用 R5_2/R5_3。 启动我的调试配置后、它连接然后运行 GEL 脚本。 我的问题发生在 main ()之前,所以我禁用了"运行到 main "。
大约10%到20%的时间、我发现 R5_2 (并且只有 R5_2) 由于执行0x0处的第一条指令而具有 UNDEF 异常。
矢量表代码 看起来似乎合理 、因此我意识到 UNDEF 的唯一发生方法是因为指令解释错误、即内核在 应处于 Arm 模式时执行第一条指令时处于 Thumb 模式。 下面的屏幕截图确认了这一点。 当我执行下一条指令时、会发生 UNDEF 异常:
当问题不发生时、这是"正常"状态:
我觉得大约有15%的时间 GEL 脚本没有正确设置 Arm 模式(或错误、意外或以其他方式设置 Thumb)。 这种情况不会在100%的时间发生这一事实表明存在一种竞争状况。
浏览 GEL 文件后、我认为问题可能出在 GEL_Reset()中。
我还注意到、与点击"CPU Reset"按钮相比、GEL_Reset ()之后的其他内核中的 CPSR 其他字段不一致。 当为所有内核点击后者时、所有内核中的 CPSR 始终为0x1D3。
但在 GEL_Reset()之后、R5_2和 R5_3中有各种值、如此处第2列所示:
内核 | CPSR 在 GEL_Reset ()之后 | "CPU Reset"之后的 CPSR。 | 结果 |
R5_0 | 0x000001D3 | 0x000001D3 | GEL_Reset()之后的 CPSR 与 CPU 复位一致。 程序始终运行。 |
R5_2 | 0x200001D7 | 0x000001D3 | GEL_Reset()之后的 CPSR 不同、但程序将运行。 |
0x800001D3 | 0x000001D3 | GEL_Reset()之后的 CPSR 不同、但程序将运行。 | |
0xA00001FB | 0x000001D3 | GEL_Reset()之后的 CPSR 不同、但由于 T = 1、程序将无法运行。 | |
R5_3 | 0x000001DB | 0x000001D3 | GEL_Reset()之后的 CPSR 不同、但程序将运行。 |
0x200001D7 | 0x000001D3 | GEL_Reset()之后的 CPSR 不同、但程序将运行。 |
大多数情况下、这种变化会被忽略、因为至少 T = 0 (Arm)且程序可以运行。 但是、有时该变体意味着 T=1且程序立即崩溃。
总之,我认为 GEL_Reset()除了在 R5_0中不能正常工作。
谢谢你。
Ming WeiPlease您能解决这个问题吗?
尊敬的 Kier:
我在过去的三个星期旅行。 我将会调查 该问题。
尊敬的 Zackary:
也许您能帮我解决这个问题吗?
尊敬的 Kier:
您可以在 GEL 文件中将 CPSR 重置为 ARM 状态:
OnPreFileLoaded()
{
GEL_Reset ();
GEL_TextOut ("CPU 复位(软复位)已通过 GEL 发出。\n");
reset_arm();
GEL_TextOut ("将 CPSR 复位为 ARM 状态、监控器模式。\n");
}
/*------------------ */
/* RESET_ARM()*/
/*将 CPSR 复位为 ARM 状态、监控器模式*/
/*------------------ */
RESET_ARM()
{
CPSR = 0x400000D3;//将 CPSR 设置为管理员模式、禁用 IRQ/FIQ
}
感谢您的回复 QJ。
我尝试了你的解决方法,但它没有解决这个问题。 在哪个内核上、CPSR 将设置为 0x400000D3? 这会影响所有内核还是仅影响内核0? 报告的问题仅发生在 Core 2上。
在此示例中、您可以看到使用 TI 空工程、即使编辑 GEL 文件、Core 2 CPSR = 0x200001F3。
此外、设置 T 标志...
...因此 发生 UNDEF 异常:
在任何情况下、 由于 TI "empty_am263x-cc_system_freertos"中也存在该问题、因此您应该能够重现该问题。 请自行尝试。
重复此操作20次。 至少一次、在程序加载后内核2上的 T = 1。 为什么?
尊敬的 Kier:
我注意到 GEL_RESET()不会将 CPSR (T 和 M[4:0])重置为默认状态。
好的,所以请实施一个 GEL_Reset()来正确且一致地重置所有内核中的 CPSR 寄存器以避免问题。
我的结论是、TI 对深入这个问题没有兴趣。 我想在一天结束时,我也可以忽略它。 毕竟、这似乎只有在 DevBoot 模式下才是问题、并且大约有20%的时间是问题。
每次复位后、引导流程序列为 RBL-SBL-Application、引导加载程序会复位内核、配置 PLL 并执行 PBIST/LBIST。 内核复位后、内核处于 ARM 模式。 在开发模式(无引导)下、我们使用 CCS 或其他带 GEL 文件的 IDE、PLL 通过 GEL 文件配置。 但 core0上的 GEL 不会重置其他 CPU 内核、并且无法初始化其他内核的寄存器(我不知道如何操作)。
为了初始化 CPU core2和 core3的 CPSR 寄存器、我已将一个简单的 GEL 文件添加到第二个和第三个内核中。 此简单 GEL 在连接目标和加载程序时仅发出 GEL 复位和 CPSR 初始化命令。 GEL 脚本与我几周前发布的脚本相同。
e2e.ti.com/.../AM263x_5F00_2nd_5F00_Core.gel
/*每次连接目标时都会调用*/
OnTargetConnect()
{
如果 (Enable_On 连接=1){
GEL_Reset ();
reset_arm();
}
}
/*它是在加载程序之前调用的。*/
OnPreFileLoaded()
{
如果 (Enable_On 连接=1){
GEL_Reset ();
reset_arm();
}
}
/*------------------ */
/* RESET_ARM()*/
/*将 CPSR 复位为 ARM 状态、监控器模式*/
/*------------------ */
RESET_ARM()
{
GEL_TextOut ("Reset CPSR \n");
CPSR = 0x400000D3;//将 CPSR 设置为监控器模式、禁用 IRQ/FIQ
}
感谢您提供解决方法。 我们现在转向 AM263 P 它由于某种原因不会出现问题。 尽管如此、如果它再次出现、我会记住这一点。