调试2440 RAM拷贝至SDRAM遇到的问题
汇编代码主要是初始化一些寄存器,关狗,初始化时钟,初始化存储管理器以便访问内存,然后将SoC上4k RAM数据拷贝至SDRAM,然后在SRAM里面运行,由于代码未正常跑起来,于是使用JLinkExe来调试。JLinkExe指定了一个命令文件: JLinkExe -commandfile ./cmd.jlink ,cmd.jlink文件内容如下:
1 r
2 loadbin /home/thomas/learn/armasm/addresses/main.bin 0x0
3 setbp 0x0 a s
4 setpc 0x0
运行至内存拷贝代码时发现了问题:
1 copy_steppingstone2sdram:
2 ldr r0,=0x30000000 @sdram start addr
3 ldr r1,=(0x30000000+4*1024) @steppingstone length + sdram start addr
4 mov r2,#0x0 @steppingstone start addr
5 copy_cycle:
6 ldr r3,[r2],#4
7 str r3,[r0],#4
8 cmp r0,r1
9 bne copy_cycle
10 mov pc,lr
代码反复分析,没发现问题,但是诡异的是:单步至第六行汇编指令时,按道理r3里面值应该是我的main.bin文件的前4个字节,输入:regs 查看各寄存器值,发现r3居然是0xDEEEDEEE,继续下一个字节的拷贝,这下r3的值又正常了。于是怀疑难道是flash这个点坏了?但是 flash不是有坏块标识机制吗?然后进一步确认下,使用命令:mem32 0x0 1,发现输出值又是对的,并不是0xDEEEDEEE。突然觉得0xDEEEDEEE这个值比较有特点,于是直接百度这个值,这下搜到了ARM官方文档,Using EmbeddedICE,这下才明白怎么回事了。主要是由于的cmd.jlink文件里面设置了一个软件断点。一般断点分为2种,1.软件断点 2.硬件断点。
1.硬件断点
硬件断点通过使用一个被称为EmbeddedICE的宏单元来监视写往地址线上的数据,如果地址匹配上则停止执行。这个宏单元是可以配置的,配置为breakpoint或者watchpoint,它会占据这个硬件单元,一般一个芯片上的EmbeddedICE宏单元数量不会太多,比如ARMv5的ARM9只有2个。也就是说至多设置2个硬件断点,如果要设置第三个,那么必须覆盖其中一个。
2.软件断点
软件断点也是通过使用EmbeddedICE宏单元来监测取指时指令是否符合一个特殊的bit-pattern,位模式,就是说取出的指令是否是个特定值,或者指令某几个位是否匹配上。这个bit-pattern会预先存储到下软件断点的位置,也就是说把在内存中哪个位置的值替换为这个bit-pattern,而原来这个位置的指令会被暂存到调试器的存储单元中。因此自修改代码,或者位于ROM中的代码是不能使用这种断点的。ROM中的很好理解,下软件断点必须往里面写bit-pattern,而ROM只读,显然不行了,自修改代码可能出现代码拷贝的动作,从源地址拷贝至目标地址,如果这个时候你在源地址某处下个软件断点,那么你拷贝到目的地址的这条指令变成了bit-paterrn了。
我遇到的问题正是由于在零地址下了个软件断点导致。软件断点个数是没限制的,所有的软件断点占据一个EmbeddedICE宏单元,也就是说对于只有2个宏单元的ARM9,你下过软件断点后就只能下一个硬件断点了。
相关文章