• State Accepted Answer
  • +1 person also asked this people also asked this
  • Locked Locked
  • Replies 3 replies
  • Subscribers 349 subscribers
  • Views 6020 views
  • Users 0 members are here
Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

what did these  Assembly codes mean?

duoduo duoduo
Note: This was originally posted on 3rd February 2009 at http://forums.arm.com

Dear all,
i debugged my codes on AXD, and the microcontroller is arm7 s3c44b0.
it ran well at the beginning, into the "main" function, did some initializations, and so on.
and then it ran into the disassembly mode. the Assembly codes were below：

026ec27c [0x2e2e2e2e]   cdpcs    p14,0x2,c2,c14,c14,1
026ec280 [0x69696969]   stmvsdb  r9!,{r0,r3,r5,r6,r8,r11,r13,r14}^
026ec284 [0x69696969]   stmvsdb  r9!,{r0,r3,r5,r6,r8,r11,r13,r14}^
026ec288 [0x69696969]   stmvsdb  r9!,{r0,r3,r5,r6,r8,r11,r13,r14}^
026ec28c [0x69696969]   stmvsdb  r9!,{r0,r3,r5,r6,r8,r11,r13,r14}^
026ec290 [0x69696969]   stmvsdb  r9!,{r0,r3,r5,r6,r8,r11,r13,r14}^
026ec294 [0x69696969]   stmvsdb  r9!,{r0,r3,r5,r6,r8,r11,r13,r14}^
026ec298 [0x69696969]   stmvsdb  r9!,{r0,r3,r5,r6,r8,r11,r13,r14}^
026ec29c [0x69696969]   stmvsdb  r9!,{r0,r3,r5,r6,r8,r11,r13,r14}^
026ec2a0 [0x69696969]   stmvsdb  r9!,{r0,r3,r5,r6,r8,r11,r13,r14}^
026ec2a4 [0x69696969]   stmvsdb  r9!,{r0,r3,r5,r6,r8,r11,r13,r14}^
026ec2a8 [0x69696969]   stmvsdb  r9!,{r0,r3,r5,r6,r8,r11,r13,r14}^
026ec2ac [0x69696969]   stmvsdb  r9!,{r0,r3,r5,r6,r8,r11,r13,r14}^
026ec2b0 [0x69696969]   stmvsdb  r9!,{r0,r3,r5,r6,r8,r11,r13,r14}^
026ec2b4 [0x69696969]   stmvsdb  r9!,{r0,r3,r5,r6,r8,r11,r13,r14}^

why this happened?according to these Assembly codes, can anybody tell me what was the microcontroller doing?
many thanks!
  • 0
    Note: This was originally posted on 3rd February 2009 at http://forums.arm.com

    It is possible that you are trying to write a software breakpoint in to a flash memory; this won't work and has a habit of putting the flash in "write mode". Reads while the flash is in write mode will return flash device control information - which often looks a little like what you are seeing.

    Try configuring your debugger to write hardware breakpoints, just be aware that the number of hardware breakpoints which can be concurrently set is often limited.


    isogen74, thank you very much!
    I tried but i couldn't find how to  configure the debugger to write hardware breakpoints.
    Can you tell me how to implement this?
    Many thanks!
  • +1 Arm Employee Badge
    Note: This was originally posted on 3rd February 2009 at http://forums.arm.com

    It is possible that you are trying to write a software breakpoint in to a flash memory; this won't work and has a habit of putting the flash in "write mode". Reads while the flash is in write mode will return flash device control information - which often looks a little like what you are seeing.

    Try configuring your debugger to write hardware breakpoints, just be aware that the number of hardware breakpoints which can be concurrently set is often limited.
  • 0 Arm Employee Badge
    Note: This was originally posted on 3rd February 2009 at http://forums.arm.com

    It's likely that the code isn't intended for execution. Notice that the instruction code is "0x69696969". I suspect that this is a default value for some memory, perhaps to be used for measuring the stack depth in your debugger.

    Having said that, it is _possible_ that it's valid code, but it's seriously unlikely.