[参考译文] MCU-PLUS-SDK AM273X：多核应用的调试不可靠

我想您可能 遇到了我在 AM2634上遇到的同样的问题。

程序加载后、其中一个内核(在本例中仅为 R5_2)可以随机处于拇指模式。 这会产生一个 UNDEF 异常、后跟 DABT。  AM2634：DevBoot 后、Cortex_R5_2有时处于 Thumb 模式。 导致 UNDEF 异常。 -基于 Arm 的微控制器论坛-基于 Arm 的微控制器- TI E2E 支持论坛

我可以重现该问题。 它似乎特定于 C66x。  

我为此提交了一个错误。 跟踪链接： https://sir.ext.ti.com/jira/browse/EXT_EP-11832

对于#1、这将需要由器件专家进行研究。 我将提请他们注意该线程。

谢谢

Ki

尊敬的 Kacper：

出现此问题的可能原因有两种：1：

1. SOC 的初始化

2. R5F 内核的 MPU 设置  

关于1的问题：

如何初始化 AM273x SOC？ GEL 文件或 SBL_NULL？

您的应用的 MPU 设置是什么？

此致、

Ming

我使用 GEL 文件。 但是、何时以及如何使用 SBL_NULL？ 我找不到任何相关文档。

MPU 配置：

谢谢你

Kacper Kowalski 关于问题1、您是否可以禁用自动运行、以便 PC 从0x0开始：

然后检查 CPSW。 T 字段。 如果它是== 1 ,就在 UNDEF 异常发生之前,那么你和我有相同的问题。

出现此问题的可能原因有两种：1：

1. SOC 的初始化

2. R5F 内核的 MPU 设置  

如果 Kacper 的问题1与  (+) AM2634中描述的我的问题(TBC)相同：在 DevBoot 之后、Cortex_R5_2有时处于 Thumb 模式。 导致 UNDEF 异常。 -基于 Arm 的微控制器论坛-基于 Arm 的微控制器- TI E2E 支持论坛

那么 会发生问题1：

• ...before _mpu_init ()被调用。 因此、它不能是一个 MPU 配置问题。
• ...大约20%的时间,因此它不可能是一个配置问题。

由于 Kacper 的问题在 QSPI 模式下不会发生、因此原因 必须仅限于 GEL 脚本的行为。

尊敬的 Kier：

同意您的分析。 我想是 SOC 初始化问题。 这就是我建议使用 SBL_NULL 来初始化 SOC 的原因。

此致、

Ming  

我没有使用 SBL_NULL 进行调试。 从闪存运行应用后、我绝不会刷写 SBL_NULL。 让我在通过 RAM 进行调试时使用 SBL_NULL、并回来报告这是否解决了不稳定调试的问题。

使用 SBL_NULL 无法解决我的所有问题。 自从我开始使用`BL_NULL`以来、我还没有得到`SHwip_undefined_handler`、但是断点不会被命中。程序加载也会在开始时随机失败、等等。

尊敬的 Kacper：

这些问题是在所有内核上发生还是仅在一个内核上发生？

它是否到达 main()？

您在哪里设置断点(无法到达哪个断点)？

当程序加载失败时、它会显示什么错误？

此致、

Ming