[参考译文] RTOS/TMS320C6657：在 C6657 EVM 上刷写外部 SPI-NOR

我已将您的疑问转发给软件专家。 他们的反馈应发布在此处。

BR
Tsvetolin Shulev

非常感谢茨韦托林。
更多信息：
我们使用 NOR 编写器实用程序对 SPI-NOR 进行了编程、并通过我们的应用程序再次检查了.bin 文件的内容。 内容相同。 因此、必须有其他东西。
BR
Martin

Martin、

根据您的描述、即使您在从以太网获取闪存编程后引导、器件也会引导应用程序、但任务创建失败、这是否正确？ 您是否在应用程序写入闪存后执行完全上电复位以引导器件。 有时、如果存在未正确初始化的堆或变量、则可能会产生不同的结果。 您可以使用仿真器和 CCS 加载符号、并查看它们是否与器件上加载的代码正确关联。

在应用程序由 RBL 引导后、在任务创建 API 之前、您可以放置一个自旋锁、以便您可以连接并查看导致故障的原因。

此致、
Rahul

非常感谢您的回答 Rahul、

问：根据您的描述、即使在通过从以太网获取闪存编程后引导、器件也会引导应用程序、但任务创建失败、这是否正确？

答：是的、正确

问： 是否在应用程序写入闪存后执行完全上电复位以引导器件。

答：是的、我们进行了 POR

问：在应用程序由 RBL 引导后、在任务创建 API 之前、您可以放置一个自旋锁、以便连接并查看导致故障的原因

答：我将在这里发布结果。

其他信息：系统很少在 IBL 上停止：从 NOR 引导

我也使用进行了编译

memset (&p_init_flags、1、sizeof (platform_init_flags))； 

 系统始终在 IBL 上停止：从 NOR 引导。

Rahul 请在哪里可以找到错误块的信息、我相信通过这个错误块我可以获得更多信息。

非常感谢

BR

Martin

你好  

好的、我发现 bin 文件未正确传输到 DSP。

我使用字节数组来存储传输的数据并连接数据串手册。

接收缓冲区的字节位置不是0x3D、而是0x00 @。 并且始终处于该位置。

我进行了以下测试：

-取了另一个 bin 文件、我得到了正确的数据

-已检查是否在 bin 文件的其他位置传输了0x3D、确定

－写入 RAM-DataCheck 的测试正常

-在 Wireshark 的情况下观察到传输的数据正常

receiveBuffer 解密如下：

在 app.cfg 中、我有： 
Program.sectMap[".far:rcvbuf"]="MSMCSRAM"； 

在 C 文件中、我有： 

#pragma DATA_SECTION (rcvbuf、".far：rcvbuf")；
#pragma DATA_ALIGN (buf、64)；
静态 char rcvbuf[1440]； 

我还尝试了不对齐和不静态的方法。

超速缓存是否有任何问题？

非常感谢您的回答

此致  

Martin

相同的行为：

#pragma DATA_SECTION (rcvbuf、".far：rcvbuf")；
#pragma DATA_ALIGN (rcvbuf、64)；
静态 char rcvbuf[1440]； 

这仅在以下 ByteCombination 中发生：

0x0F3D  

既不与0x0E3d 搭配、也不与0x0F2D 搭配

BR Martin