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.
工具/软件:TI-RTOS
我有一个从CCS运行的项目,也从NOR Flash运行。 我需要将RTSC和SYS/BIOS添加到项目中。 当我这样做的时候,.out文件增长了3倍(93K到247K) ,项目仍然可以从CCS正常运行,但当我将它刻录到NOR Flash时,它不会启动。 唯一的区别是RTSC和SYS/BIOS。 大小是问题还是RTSC? 我正在刻录.out文件并让IBL启动它。 它在没有RTSC的情况下工作。 建议?
否,我尝试从L2SRAM运行。 我们的硬件员工,以他们的无限智慧,决定我们不需要一个臭的DDR,所以我们的生产板上不会有任何东西。 Linker.cmd文件将所有内容指向L2SRAM。 BIOS中的某些内容是否可以尝试从DDR运行而未初始化? 我看了一下.map文件,但它在我看来并不是这样。 但如果我能弄清楚 如何连接它,我就会。 我正在使用6678 l 程序(稍作修改)。 我不认为它在将映像写入闪存时出现问题,因为它会读取并验证它。 我想我可以写一些代码从闪存中读取它,然后根据磁盘上的映像自己验证它。 好的,我想我上传了文件,但它看起来有点傻。 请告诉我是否做错了,如果是,如何正确操作!
我只想查看与PLL和bootloader对应的调试日志。 它确实显示启动已完成,所以我有点困惑为什么程序计数器位于0x20b0万,它是ROM bootloader的基础。 DEVSTAT寄存器指示I2C启动 ,这是正确的,因为您首先启动IBL,但主PLL寄存器指示它们尚未编程:
C66xx_0:凝胶输出:PLLD:0
C66xx_0:凝胶输出:PLLM[12:6]:0
C66xx_0:凝胶输出:旁路:0
C66xx_0:凝胶输出:BWADJ[7:0]:9
C66xx_0:凝胶输出:BWADJ[11:8]:0
您能否提供一种方法,让我在安装时重现此问题?
此致,
拉胡尔
这是我刻录到或偏移0的.out文件(使用6678 l)
Rahul,
我没有达到任何这种断点。 不知道还有什么可以尝试的
Rahul,
我在查看生成的.bin文件,与我的非RTSC项目生成的.bin文件相比,该文件在末尾看起来很奇怪。 我想知道我的.RMD文件是否需要与RTSC项目不同的内容? 下面是其中的内容:
Swift_Core1_5.out
A
引导
-e _c_int00
ROM
{
ROM1:org=0x80万,len=0x8万,romwidth=32,memwidth=32
文件={Swift_Core1_5.btbl}
}
我使用的是CCS版本6.1 .2.0.0015万
编译器是TI v.8.1 .3 (C6000系列)
我不是正数,哪个部分得到了错误的字节计数,但我猜是.switch部分? 这是第四个部分正在损坏,下面是我在构建时看到的内容:
正在转换为ASCII十六进制格式...
"Swift_Core1_5.ut".text ==>(启动表)
"Swift_Core1_5.out .cinit =>(启动表)
"Swift_Core1_5.out .const ==>(启动表)
"Swift_Core1_5.out .switch ==>(启动表)
"Swift_Core1_5.ut".vecs ==>(启动表)
David
此论坛线程 讨论了hex6x正确地向节添加一些填充字节的情况。 也许情况就是这样。
谢谢,此致,
-George
关于.const部分的引导表条目,您询问...
DAVID Hague 说:标题是否应该表示额外的2个字节?[/QUOT]
可能是这样。 如果您提交.out文件,以便我们重现问题,我将不胜感激。 请将其放入.zip文件中,然后再将其附加到下一篇文章中。
作为解决方法,您可以告诉链接器对齐.const部分并使用palign指令进行填充。 请在 C6000装配工具手册中标题为"使用填充对齐"的章节中阅读更多信息。 由于.const部分与8字节边界对齐,因此需要使用palign (8)。
谢谢,此致,
-George
George,我的core0应用程序也有问题。 我正在将.out文件写入NOR闪存以供IBL加载。 在我将应用程序转换为RTSC项目之前,这种方法运行正常,现在它无法加载。 是否属于类似问题? 如何解决此问题? 如果L2SRAM有所不同,我会尝试耗尽它。[/QUOT]
不幸的是,这一问题远远超出了我的专长。 这似乎不是类似的问题。 我建议您在 Keystone设备论坛中开始新的话题。
谢谢,此致,
-George
e2e.ti.com/.../SWIT_5F00_Core1_5F00_5.zipGeorge,
下面是压缩的.out文件。
感谢你的帮助。
David
我对拖延表示歉意。
很遗憾,我无法重现该.out文件的问题。 问题部分为.const。 以下是.btbl文件(十六进制实用程序输出)中该部分的开头...
00 00 00 2E 1E 00 81 FA C8 69 5F 41 00 69 74 69 6E
我把它分成每行32位,以便于参考。 第1行是长度。 第2行是地址。 其余的是数据。 这与.const的.out文件中的内容完全匹配。 查看此信息的一种方法是使用ofd6x输出...
部分信息 ID名称 load addr run addr.(加载地址运行地址 大小对齐分配 --- ------------------- ----------------- -------- ——— <跳过某些行> 9。常量 0x0081fac8 0x0081fac8 0x2e1e 8年
谢谢,此致,
-George
George,
如果我错了,请更正我,但您确实重现了此问题。 对于该段,.out文件的大小为0x2e1e,但hex6x工具垫块该段的大小为0x2e20,但不更新启动表中的大小。 因此,解析此文件的Bootloader在解析时被占用2个字节并丢失。 如果您查看段的底部,您可以清楚地看到插入的额外2个填充字节:
00 01 80 37 80 03 00 00 00 10 00 01 00 80 09 80 0B 80 0A 19 33 00 01
7F FF 00 01 00 00 40 00
00 00 00 38 00 82 6E E8 00 80 75 00 80 76 70 00 80 76 70 00 80 76 70 70 70
但是,我可以通过强制链接器对段进行填充并在标题中放置正确大小来解决此问题。 在我的linker.cmd文件中:
const palign (8),fill = 0x00{}> L2SRAM
现在我得到:
00 00 2E 20
...
00 01 80 37 80 03 00 00 00 10 00 01 00 80 09 80 0B 80 0A 19 33 00 01
7F FF 00 01 00 00 40 00
00 00 00 38 00 82 6E E8 00 80 75 00 80 76 70 00 80 76 70 00 80 76 70 70 70