Jlink 软件断点和硬件断点

调试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,你下过软件断点后就只能下一个硬件断点了。