c6657 core1加载失败问题咨询

Ray Gong

大家好，我在自己设计的板卡上调试C6657 SPI BOOT加载时遇到core0程序正常执行，core1程序执行异常的情况，具体情况如下:

1、BOOT程序、core0、core1应用程序存储在SPI-Flash中，在core0上运行BOOT程序，将core0、core1应用程序加载到DDR执行，实际发现core0程序能够加载成功、跳转至_c_int00运行正常，core1程序被加载成功、设置magic address、IPCGR寄存器0x0x02620244设置为1，但实际发现core1的程序main未执行。

2、通过仿真器单独加载core1应用程序main执行正常，可以排除core1应用程序本身异常导致加载失败的情况。

3、通过仿真器调试BOOT程序发现core1程序已正确加载到DDR中、且core1 boot magic address(0x118FFFFC)已写入_c_int00地址，同时在0x02620244寄存器写入1，通知core1执行，boot加载逻辑应该没问题。

4、仿真器连接core1程序，发现pc指针指向0x20B00650，处于bootrom idle阶段，表现像是没有响应IPC中断，未跳转至_c_int00执行。如果此时人为将pc指针指向_c_int00，单步执行后能进入main执行。

从以上分析，大致可以判定，boot程序(已在其他板卡c6657上试用加载从核成功)、core1应用程序本身应该没有问题。到底什么原因导致从核加载后继续在bootrom阶段，还请帮忙分析下，谢谢。

8 年多前

0 john4 8 年多前

Prodigy 153 points

我看到好多这样的问题，觉得可能是工具链生成对应.dat文件时产生的问题，好像程序默认有个最大值

0 Ray Gong 8 年多前回复 john4

Prodigy 61 points

我看论坛里的byteswapccs.exe工具跟我本地是一样，如果是工具链的问题的话，有什么方式可以绕过去吗？

0 john4 8 年多前

Prodigy 153 points

我也遇到这这个问题，我是在cmd文件中执行代码段分配出现了问题，希望能够帮到你

0 Ray Gong 8 年多前回复 john4

Prodigy 61 points

问题已经解决了，core0应用程序对boot程序数据有覆盖，导致写IPC寄存器失败。

原因:

写IPC寄存器采用的是CSL包提供的一个全局指针去操作，gpBootCfgRegs全局指针分配至L2空间，core0应用程序加载后将该全局指针覆盖，导致写IPC寄存器失败。

gpBootCfgRegs->IPCGR[1] |= 0x00000001;

解决办法:

1、对boot程序中关键代码、全局变量做好保护。

2、直接通过寄存器地址直接访问，如:

#define IPCGR1 (*(Uint32*)(0x02620244))

IPCGR1 = 0x1;

0 Ray Gong 8 年多前回复 john4

Prodigy 61 points

问题已经解决了，core0应用程序对boot程序数据有覆盖，导致写IPC寄存器失败。

原因:

写IPC寄存器采用的是CSL包提供的一个全局指针去操作，gpBootCfgRegs全局指针分配至L2空间，core0应用程序加载后将该全局指针覆盖，导致写IPC寄存器失败。

gpBootCfgRegs->IPCGR[1] |= 0x00000001;

解决办法:

1、对boot程序中关键代码、全局变量做好保护。

2、直接通过寄存器地址直接访问，如:

#define IPCGR1 (*(Uint32*)(0x02620244))

IPCGR1 = 0x1;

0 Ray Gong 8 年多前回复 john4

Prodigy 61 points

问题已经解决了，core0应用程序对boot程序数据有覆盖，导致写IPC寄存器失败。

原因:

写IPC寄存器采用的是CSL包提供的一个全局指针去操作，gpBootCfgRegs全局指针分配至L2空间，core0应用程序加载后将该全局指针覆盖，导致写IPC寄存器失败。

gpBootCfgRegs->IPCGR[1] |= 0x00000001;

解决办法:

1、对boot程序中关键代码、全局变量做好保护。

2、直接通过寄存器地址直接访问，如:

#define IPCGR1 (*(Uint32*)(0x02620244))

IPCGR1 = 0x1;

处理器

处理器论坛

c6657 core1加载失败问题咨询