Debug 2440 RAM Copy to SDRAM encountered problem

The assembler code primarily initializes some registers, shuts down the dog, initializes the clock, initializes the storage Manager to access the memory, and then copies the 4k RAM data on the SOC to the SDRAM, then runs inside the SRAM, and then uses Jlinkexe to debug because the code does not run properly. Jlinkexe Specifies a command file: jlinkexe-commandfile./cmd.jlink , the Cmd.jlink file contains the following:

1 R 2 0x0 3 0x0 a S 4 0x0

A problem was found when running to memory copy code:

1 Copy_steppingstone2sdram:2 Ldr r0,=0x30000000 @sdram start addr3Ldr r1,= (0x30000000+4*1024x768) @steppingstone length + SDRAM start addr4     movR2, #0x0 @steppingstone start addr5 copy_cycle:6LDR r3,[r2],#47     Strr3,[r0],#48     CMPR0,R19 bne copy_cycleTen     movPc,lr

Code repeated analysis, did not find the problem, but the strange thing is: Single step to the sixth Line Assembly instructions, according to the truth R3 face value should be the first 4 bytes of my main.bin file, input: regs view each register value, found R3 Incredibly is 0xDEEEDEEE, continue the next byte copy, The value of the R3 is normal again. So the suspicion is flash this point is broken? But does Flash have a bad block identification mechanism? Then further confirmation, using the command: Mem32 0x0 1, found that the output value is also right, not 0xDEEEDEEE. Suddenly feel 0xDEEEDEEE this value compared has characteristic, so direct Baidu This value, this search to arm official document, Using Embeddedice, this only then understand how to go. The main reason is that a software breakpoint is set inside the Cmd.jlink file. The general breakpoint is divided into 2 kinds, 1. Software Breakpoint 2. Hardware breakpoint.

1. Hardware breakpoints

Hardware breakpoints Monitor data written to the address line by using a macro unit called Embeddedice, which stops execution if the address matches. This macro unit is configurable, configured as breakpoint or Watchpoint, it will occupy this hardware unit, generally a chip on the Embeddedice macro unit number is not too much, such as ARMv5 ARM9 only 2. This means that at most 2 hardware breakpoints are set, and if you want to set a third, you must overwrite one of them.

2. Software breakpoints

A software breakpoint is also used to monitor whether the directive conforms to a special bit-pattern, bit pattern by using the Embeddedice macro unit, that is, whether the instruction taken is a specific value, or whether a certain number of bits match. This bit-pattern is pre-stored in the location of the software breakpoint, that is, where the value in memory is replaced with the Bit-pattern, and the original instruction in this position is staged to the debugger's storage unit. Therefore, code that is self-modifying, or that is located in ROM, cannot use this breakpoint. Rom in a good understanding, the software breakpoint must be written inside the Bit-pattern, and ROM read-only, obviously not, since the code can be copied code copy of the action, from the source address to the destination address, if you at the source address somewhere next software breakpoint, Then the instructions you copied to the destination address became BIT-PATERRN.

The problem I encountered was caused by a software breakpoint at the 0 address. The number of software breakpoints is unlimited, all software breakpoints occupy a Embeddedice macro unit, that is, for only 2 macro units of the ARM9, you have been a software breakpoint after the next hardware breakpoint.

Debug 2440 RAM Copy to SDRAM encountered problem