Other Parts Discussed in Thread: SYSCONFIG
器件型号： TDA4VE-Q1
主题： SysConfig 中讨论的其他器件
尊敬的 TI 专家：
SW：SDK10.1
HW：我们的定制电路板
在引导测试期间、系统偶尔会在 Linux 内核引导期间卡住、大约每 3000 次引导尝试就卡住一次。
通过 CCS 连接时、发现所有内核都卡在错误处理功能中。 如“Memory Browser“中所示、当尝试通过 CCS 将值写入 DDR 时、所有数据都重置为零。
图中显示了详细的 Linux 调用堆栈：
以下是悬挂和正常情况下的输出：
此致
顺便说一下、我们在正常启动期间观察到了一种异常现象。 我们的 DDR 配置包括 DDR0 (2GB K4F6E3S4HB-KHCL) 和 DDR1 (1GB K4F8E3S4HD-GHCL)、总容量为 3GB、启用了交错模式。 如图所示、我们发现 DDR0 和 DDR1 的初始化值有很大不同：在交错区域内、DDR0（涵盖从 0x0080000000 到 0x008000007F 的地址范围）将其数据初始化为 0xFF。 相比之下、后续的 DDR1 段（跨越地址 0x0080000080 至 0x00800000FF）的初始化数据设置为 0x00。 DDR INTERLEAVE 区域值不同是否正常？
您好、 Tanmay、
我们已启用内核日志记录、目前正在进行测试。
启用内核日志记录后、Linux 无法通过 UART 输出错误消息。 以下是悬挂和正常情况下的输出：
e2e.ti.com/.../hang_2D00_kernel.loge2e.ti.com/.../ok_2D00_kernel.log
以下是通过 CCS 获取的调用栈信息。
此致
尊敬的 TI 专家：
在新的启动挂起过程中、我们发现了一个重要的线索：
如下图所示、 MCU2_0 内核的栈指针变量 pxStack（地址 0xA28AEF58） 被 0x00 意外覆盖、导致系统挂起栈溢出检查。
进一步检查附近存储器区域后发现异常访问边界：
地址 0xA28AF07F 不可写、并且前面的 128‑字节范围 (0xA28AF000–0xA28AF07F、偏移 0x0–0x7F) 用零填充、并且完全无法访问（既不可读，也不可写）。
地址 0xA28AF080 是可写的、并且以下 128‑字节范围 (0xA28AF080–0xA28AF0FF、偏移 0x80–0xFF) 正常运行。
0x7F/0x80 边界与 128‑字节分段对齐。 在我们的存储器映射中、0x0–0x7F 范围属于 DDR0 的一个段、而 0x80–0xFF 属于 DDR1 的一个段。
发生故障时、整个 DDR0 区域变得不可读/不可写并读为全零、而 DDR1 区域保持完全正常工作。 这可能是什么原因？
此致
您好 、Brijesh、
下面是我们当前的 DDR 配置。 您能回顾一下吗？
我们已经发现、在新的 DDR0 SysConfig 中默认启用数据总线反转。 此修改的目的是什么？
此致
