EmbDev.net

Forum: ARM programming with GCC/GNU tools GDB issue (cortex-M3)


Author: Ar Lc (al2757)
Posted on:

Rate this post
0 useful
not useful
Hello everybody,

I am working on a STM3210E-EVAL board for 2 weeks now and there are some
odd things happening when I use the GDB provided with WinARM(gdb version
6.4.50.20060226-cvs).

I use Eclipse as a IDE, everything seems to be working fine until I
reach some instructions that need to work with register R7('mov.w r7,0'
or 'mov.w r7,r7,#12', also an add.w r7 creates the same outcome), I took
a look on the packages sent by gdb and this is what it sends:

Sending packet: $m2000037e,2#8c...Ack
Packet received: 80bc
Sending packet: $m20000380,2#58...Ack
Packet received: 7047
Sending packet: $Hc0#db...Ack
Packet received:
Sending packet: $s#73...Ack
Packet received: O7461726765742073746174653a2068616c7465640a
Packet received:
O7461726765742068616c74656420696e205468756d622073746174652064756520
746f2073696e676c6520737465702c2063757272656e74206d6f64653a205468726561
64200a785053523a20307830313030303030302070633a20307832303030303332320a
target state: halted
target halted in Thumb state due to single step, current mode: Thread
xPSR: 0x01000000 pc: 0x20000322
Packet received: T05
Sending packet: $g#67...Ack
Packet received:
0000000000000080e04f0020020000003600000037000000ffffbff700000000
ffffffffffffbff73d0000006dddfe4810000000bc4f00204d2600202303002000000000 
0
000000000000000000000000000000000000000000000000000000000000000000000000 
0
000000000000000000000000000000000000000000000000000000000000000000000000 
0
00000000000000000000000000000000000000000000000000001
Sending packet: $m20000322,4#56...Ack
Packet received: 07f10c07
Sending packet: $m3c,4#63...Ack
Packet received: E0E

The "Sending packet: $m3c,4#63...Ack" is what actually this error is
about, normally that package should not exist and it happens only when I
try "mov.w r7,0", if I try "mov.w r1,0" this packet doesn't get sended.

Everything works fine(single stepping,watches,and so on) except for this
problem.

Any ideas?

Thank you in advance!

LC

Author: Martin Thomas (mthomas) (Moderator)
Posted on:

Rate this post
0 useful
not useful
The tools in WinARM (even in the "latest" test-release) are a little 
outdated. I currently do not plan to build a new WinARM since 
Codesourcery's package includes everything I currently need for my hobby 
and professional work. I suggest to try again with the tools from 
Codesourcery (arm-eabi "bare metal" for Win32 hosts). The lite version 
is free. For a quick start just install the Codesourcery package and 
replace the prefix for all GNU tools with arm-none-eabi-, i.e. 
arm-elf-gdb (WinARM) -> arm-none-eabi-gdb (CS).

Maybe the information in this project will help:
http://www.siwawi.arubi.uni-kl.de/avr_projects/arm...
During development I have used Eclipse Ganymede, CDT, CDT 
hardware-debugging-plugin, Codesourcery G++ lite for ARM-eabi 2009Q1, 
OpenOCD (different but rather up-to-date versions), Amontec JTAGkey, 
FTDI-drivers and STM32F103CB for the tests. Debugging from Eclipse works 
as expected (well, at least what I expected/needed). A little bit of 
additional information can be found in the readme.txt.

Author: Ar Lc (al2757)
Posted on:

Rate this post
0 useful
not useful
Hi Martin,

  Thanks for the reply, I will try this.

  Regarding the following:

  "During development I have used Eclipse Ganymede, CDT, CDT
hardware-debugging-plugin, Codesourcery G++ lite for ARM-eabi 2009Q1,
OpenOCD (different but rather up-to-date versions), Amontec JTAGkey,
FTDI-drivers and STM32F103CB for the tests. Debugging from Eclipse works
as expected (well, at least what I expected/needed). A little bit of
additional information can be found in the readme.txt."

  I am also using Eclipse Ganymede CDT, Codesourcery G++ Lite for 
ARM-eabi 2009Q1, OpenOCD but with an Olimex ARM USB OCD. For debugging I 
used the gdb from WinARM since it was the only one I could configure and 
did all the stuff I needed. I will try with the gdb from Codesourcery 
although that gdb never worked properly when I tried it(today,it 
executes stept by step but doesn't show me the registers and when I hit 
run to execute the code until a breakpoint everything goes south when I 
do this).
  I will have a look at your example.

  Thank you!

Lucian

P.S. I am also using CS-EP9302 from olimex and I never had a problem 
with the gdb(arm-elf-gdb).

Author: Martin Thomas (mthomas) (Moderator)
Posted on:

Rate this post
0 useful
not useful
Ar Lc wrote:
>...
>   Regarding the following:
>
>   "During development I have used Eclipse Ganymede, CDT, CDT
> hardware-debugging-plugin, Codesourcery G++ lite for ARM-eabi 2009Q1,
> OpenOCD (different but rather up-to-date versions), Amontec JTAGkey,
> FTDI-drivers and STM32F103CB for the tests. Debugging from Eclipse works
> as expected (well, at least what I expected/needed). A little bit of
> additional information can be found in the readme.txt."
>
>   I am also using Eclipse Ganymede CDT, Codesourcery G++ Lite for
> ARM-eabi 2009Q1, OpenOCD but with an Olimex ARM USB OCD. For debugging I
> used the gdb from WinARM since it was the only one I could configure and
> did all the stuff I needed.

I had problems with the gdb from CS G++ lite 2008Q3. So I have used the 
one from DevkitARM for some time (both are cross-toolchains for arm-eabi 
targets). But so far I have had no problems with the gdb from G++ 
2009Q1.
Do you use CDT gdb hardware debugging plugin or the Zylin plugin? Both 
are similar but not the same.

Olimex ARM USB OCD and Amontec JTAGkey are very similar (I don't own an 
Olimex interface). As far is I know the only differences are the routing 
of the reset-lines to the FT2232 and different level-convertes (JTAGkey 
can handle lower target voltages).

OpenOCD also plays an important role and is still under heavy 
development. If you are using an old version please try with a new one 
(maybe even a binary compiled from the SVN sources). I'm currently using 
OpenOCD SVN2660 with FTDI-Drivers from 2/2009.

> I will try with the gdb from Codesourcery
> although that gdb never worked properly when I tried it(today,it
> executes stept by step but doesn't show me the registers and when I hit
> run to execute the code until a breakpoint everything goes south when I
> do this).
>   I will have a look at your example.

Not related to debugging: There is one know issue with the current 
release of my STM32 SD demo: If you see errors about missing files in 
...dep... during make please create a directory FLASH_RUN and a 
subdirectory dep in it. I will upload a package with a fixed makefile 
soon.

>...
> P.S. I am also using CS-EP9302 from olimex and I never had a problem
> with the gdb(arm-elf-gdb).

So far I have not "played" with Cirrus devices. I expect the older 
gdb-version have been heavily tested with "mature" ARM-cores like the 
ARM9 in the EP9302. CM3 is a rather new core so maybe there are some 
minor glitches.

Good luck,
Martin

Author: Ar Lc (al2757)
Posted on:

Rate this post
0 useful
not useful
Hi Martin,

  Yes, I am using the CDT from Zylin, I've tried both CDT gdb hardware 
debugging and Zylin, so far I am working with the one from Zylin(I've 
tried the CDT gdb hardware debugging with the gdb from Codesourcery and 
that didn't work to well).
  I will try some things today, hope everything works fine.

  Thank you!


  Lucian

Author: Ar Lc (al2757)
Posted on:

Rate this post
0 useful
not useful
Hi Martin,

  Tried some things today,everything worked fine for an hour or so with 
the gdb from your example (Devkit) now I get the same problem at "mov.w 
r7,0". :-)
  I'll try to compile a newer version of OpenOCD although when I do a 
step by step operation with openOCD using telnet this problem doesn't 
occur.

  Thank you for everything!

  Lucian

"Debug:   759 29375 cortex_m3.c:284 
cortex_m3_examine_exception_reason(): External Interrupt(16) SHCSR 
0x20000, SR 0x0, CFSR 0xffffffff, AR 0xffffffff
Debug:   760 29375 cortex_m3.c:342 cortex_m3_debug_entry(): entered 
debug state in core mode: Handler at PC 0x20000206, target->state: 
halted
Debug:   761 29375 target.c:585 target_call_event_callbacks(): target 
event 0
Debug:   762 29375 cortex_m3.c:694 cortex_m3_step(): target stepped 
dcb_dhcsr = 0x3000f nvic_icsr = 0x0
Debug:   763 29375 gdb_server.c:1815 gdb_input_inner(): received packet: 
'g'
Debug:   764 29375 gdb_server.c:1815 gdb_input_inner(): received packet: 
'm20000206,4'
Debug:   765 29375 gdb_server.c:1061 gdb_read_memory_packet(): addr: 
0x20000206, len: 0x00000004
Debug:   766 29375 target.c:896 target_read_buffer(): reading buffer of 
4 byte at 0x20000206
Debug:   767 29422 gdb_server.c:1815 gdb_input_inner(): received packet: 
'm14,4'
Debug:   768 29422 gdb_server.c:1061 gdb_read_memory_packet(): addr: 
0x00000014, len: 0x00000004
Debug:   769 29422 target.c:896 target_read_buffer(): reading buffer of 
4 byte at 0x00000014
Debug:   770 29422 cortex_swjdp.c:208 swjdp_transaction_endcheck(): 
swjdp: CTRL/STAT error 0xf0000021
Error:   771 29422 cortex_swjdp.c:222 swjdp_transaction_endcheck(): 
SWJ-DP STICKY ERROR
Debug:   772 29422 cortex_swjdp.c:229 swjdp_transaction_endcheck(): 
swjdp: status 0xf0000001
Error:   773 29453 cortex_swjdp.c:236 swjdp_transaction_endcheck(): 
dcb_dhcsr 0x103000f, nvic_shcsr 0x20000, nvic_cfsr 0x0, nvic_bfar 
0xe000edf8
Debug:   774 29468 cortex_swjdp.c:208 swjdp_transaction_endcheck(): 
swjdp: CTRL/STAT error 0xf0000021
Error:   775 29468 cortex_swjdp.c:222 swjdp_transaction_endcheck(): 
SWJ-DP STICKY ERROR
Debug:   776 29468 cortex_swjdp.c:229 swjdp_transaction_endcheck(): 
swjdp: status 0xf0000001
Error:   777 29500 cortex_swjdp.c:236 swjdp_transaction_endcheck(): 
dcb_dhcsr 0x3000f, nvic_shcsr 0x20000, nvic_cfsr 0x0, nvic_bfar 
0xe000edf8
Warning: 778 29500 cortex_swjdp.c:703 ahbap_read_buf_u32(): Block read 
error address 0x14, count 0x1
Error:   779 29500 gdb_server.c:1022 gdb_error(): unexpected error -107
Debug:   780 29500 gdb_server.c:1815 gdb_input_inner(): received packet: 
'qL1200000000000000000'
Debug:   781 29500 gdb_server.c:1815 gdb_input_inner(): received packet: 
'qC'
Debug:   782 29515 gdb_server.c:1815 gdb_input_inner(): received packet: 
'm200082d0,1'
Debug:   783 29515 gdb_server.c:1061 gdb_read_memory_packet(): addr: 
0x200082d0, len: 0x00000001
Debug:   784 29515 target.c:896 target_read_buffer(): reading buffer of 
1 byte at 0x200082d0
Debug:   785 29531 gdb_server.c:1815 gdb_input_inner(): received packet: 
'm200082d1,1'
Debug:   786 29531 gdb_server.c:1061 gdb_read_memory_packet(): addr: 
0x200082d1, len: 0x00000001
Debug:   787 29531 target.c:896 target_read_buffer(): reading buffer of 
1 byte at 0x200082d1
Debug:   788 29531 gdb_server.c:1815 gdb_input_inner(): received packet: 
'm200082ee,2'
Debug:   789 29531 gdb_server.c:1061 gdb_read_memory_packet(): addr: 
0x200082ee, len: 0x00000002
Debug:   790 29531 target.c:896 target_read_buffer(): reading buffer of 
2 byte at 0x200082ee"

Author: Ar Lc (al2757)
Posted on:

Rate this post
0 useful
not useful
Hi,

  Worked with the Codesourcery gdb and this one "cracks" always at 
instruction "bx lr", I checked the lr register and other registers and 
everything is ok.


Open On-Chip Debugger
> reg
(0) r0 (/32): 0x2000ffc4 (dirty: 1, valid: 1)
(1) r1 (/32): 0x4001040c (dirty: 0, valid: 1)
(2) r2 (/32): 0x00000000 (dirty: 0, valid: 1)
(3) r3 (/32): 0x00000020 (dirty: 0, valid: 1)
(4) r4 (/32): 0xffffbfef (dirty: 0, valid: 1)
(5) r5 (/32): 0xffbfef00 (dirty: 0, valid: 1)
(6) r6 (/32): 0x4b1ab008 (dirty: 0, valid: 1)
(7) r7 (/32): 0x2000ffa4 (dirty: 0, valid: 1)
(8) r8 (/32): 0xffffffff (dirty: 0, valid: 1)
(9) r9 (/32): 0xf7bfffff (dirty: 0, valid: 1)
(10) r10 (/32): 0xa1a5896d (dirty: 0, valid: 1)
(11) r11 (/32): 0x48fefd6d (dirty: 0, valid: 1)
(12) r12 (/32): 0xfdfdffff (dirty: 0, valid: 1)
(13) sp (/32): 0x2000ffa4 (dirty: 0, valid: 1)
(14) lr (/32): 0x200018df (dirty: 0, valid: 1)
(15) pc (/32): 0x20004ffd (dirty: 1, valid: 1)
(16) xPSR (/32): 0x81000025 (dirty: 0, valid: 1)
(17) msp (/32): 0x2000ffa4 (dirty: 0, valid: 1)
(18) psp (/32): 0x2000a000 (dirty: 0, valid: 1)
(19) primask (/32): 0x00000000 (dirty: 0, valid: 1)
(20) basepri (/32): 0x00000000 (dirty: 0, valid: 1)
(21) faultmask (/32): 0x00000000 (dirty: 0, valid: 1)
(22) control (/32): 0x00000000 (dirty: 0, valid: 1)
target state: halted
target halted in Thumb state due to single step, current mode: Handler 
External
Interrupt(21)
xPSR: 0x81000025 pc: 0x20004ffe
target state: halted
target halted in Thumb state due to single step, current mode: Handler 
External
Interrupt(21)
xPSR: 0xa1000025 pc: 0x20005000
target state: halted
target halted in Thumb state due to single step, current mode: Handler 
External
Interrupt(21)
xPSR: 0xa1000025 pc: 0x20005002
target state: halted
target halted in Thumb state due to single step, current mode: Handler 
External
Interrupt(21)
xPSR: 0xa1000025 pc: 0x20005004
SWJ-DP STICKY ERROR
dcb_dhcsr 0x103000f, nvic_shcsr 0x20000, nvic_cfsr 0x0, nvic_bfar 
0xe000edf8
SWJ-DP STICKY ERROR
dcb_dhcsr 0x3000f, nvic_shcsr 0x20000, nvic_cfsr 0x0, nvic_bfar 
0xe000edf8
Block read error address 0x2255114, count 0x1
unexpected error -107
SWJ-DP STICKY ERROR
dcb_dhcsr 0x3000f, nvic_shcsr 0x20000, nvic_cfsr 0x0, nvic_bfar 
0xe000edf8
SWJ-DP STICKY ERROR
dcb_dhcsr 0x3000f, nvic_shcsr 0x20000, nvic_cfsr 0x0, nvic_bfar 
0xe000edf8
Block read error address 0x2255104, count 0x1
unexpected error -107
SWJ-DP STICKY ERROR
dcb_dhcsr 0x3000f, nvic_shcsr 0x20000, nvic_cfsr 0x0, nvic_bfar 
0xe000edf8
SWJ-DP STICKY ERROR
dcb_dhcsr 0x3000f, nvic_shcsr 0x20000, nvic_cfsr 0x0, nvic_bfar 
0xe000edf8
Block read error address 0x2255114, count 0x1
unexpected error -107
SWJ-DP STICKY ERROR
dcb_dhcsr 0x3000f, nvic_shcsr 0x20000, nvic_cfsr 0x0, nvic_bfar 
0xe000edf8
SWJ-DP STICKY ERROR
dcb_dhcsr 0x3000f, nvic_shcsr 0x20000, nvic_cfsr 0x0, nvic_bfar 
0xe000edf8
Block read error address 0x2255114, count 0x1
unexpected error -107
SWJ-DP STICKY ERROR
dcb_dhcsr 0x3000f, nvic_shcsr 0x20000, nvic_cfsr 0x0, nvic_bfar 
0xe000edf8
SWJ-DP STICKY ERROR
dcb_dhcsr 0x3000f, nvic_shcsr 0x20000, nvic_cfsr 0x0, nvic_bfar 
0xe000edf8
Block read error address 0x2255114, count 0x1
unexpected error -107
SWJ-DP STICKY ERROR
dcb_dhcsr 0x3000f, nvic_shcsr 0x20000, nvic_cfsr 0x0, nvic_bfar 
0xe000edf8
SWJ-DP STICKY ERROR
dcb_dhcsr 0x3000f, nvic_shcsr 0x20000, nvic_cfsr 0x0, nvic_bfar 
0xe000edf8
Block read error address 0x2255114, count 0x1
unexpected error -107
SWJ-DP STICKY ERROR
dcb_dhcsr 0x3000f, nvic_shcsr 0x20000, nvic_cfsr 0x0, nvic_bfar 
0xe000edf8
SWJ-DP STICKY ERROR
dcb_dhcsr 0x3000f, nvic_shcsr 0x20000, nvic_cfsr 0x0, nvic_bfar 
0xe000edf8
Block read error address 0x2255114, count 0x1
unexpected error -107
SWJ-DP STICKY ERROR
dcb_dhcsr 0x3000f, nvic_shcsr 0x20000, nvic_cfsr 0x0, nvic_bfar 
0xe000edf8
SWJ-DP STICKY ERROR
dcb_dhcsr 0x3000f, nvic_shcsr 0x20000, nvic_cfsr 0x0, nvic_bfar 
0xe000edf8
Block read error address 0x2255114, count 0x1
unexpected error -107
SWJ-DP STICKY ERROR
dcb_dhcsr 0x3000f, nvic_shcsr 0x20000, nvic_cfsr 0x0, nvic_bfar 
0xe000edf8
SWJ-DP STICKY ERROR
dcb_dhcsr 0x3000f, nvic_shcsr 0x20000, nvic_cfsr 0x0, nvic_bfar 
0xe000edf8
Block read error address 0x2255114, count 0x1
unexpected error -107
SWJ-DP STICKY ERROR
dcb_dhcsr 0x3000f, nvic_shcsr 0x20000, nvic_cfsr 0x0, nvic_bfar 
0xe000edf8
SWJ-DP STICKY ERROR
dcb_dhcsr 0x3000f, nvic_shcsr 0x20000, nvic_cfsr 0x0, nvic_bfar 
0xe000edf8
Block read error address 0x2255114, count 0x1
unexpected error -107
SWJ-DP STICKY ERROR
dcb_dhcsr 0x3000f, nvic_shcsr 0x20000, nvic_cfsr 0x0, nvic_bfar 
0xe000edf8
SWJ-DP STICKY ERROR
dcb_dhcsr 0x3000f, nvic_shcsr 0x20000, nvic_cfsr 0x0, nvic_bfar 
0xe000edf8
Block read error address 0x2255114, count 0x1
unexpected error -107
SWJ-DP STICKY ERROR
dcb_dhcsr 0x3000f, nvic_shcsr 0x20000, nvic_cfsr 0x0, nvic_bfar 
0xe000edf8
SWJ-DP STICKY ERROR
dcb_dhcsr 0x3000f, nvic_shcsr 0x20000, nvic_cfsr 0x0, nvic_bfar 
0xe000edf8
Block read error address 0x2255104, count 0x1
unexpected error -107
SWJ-DP STICKY ERROR
dcb_dhcsr 0x3000f, nvic_shcsr 0x20000, nvic_cfsr 0x0, nvic_bfar 
0xe000edf8
SWJ-DP STICKY ERROR
dcb_dhcsr 0x3000f, nvic_shcsr 0x20000, nvic_cfsr 0x0, nvic_bfar 
0xe000edf8
Block read error address 0x225510c, count 0x1
unexpected error -107
> reg
(0) r0 (/32): 0x2000ffc4 (dirty: 1, valid: 1)
(1) r1 (/32): 0x4001040c (dirty: 0, valid: 1)
(2) r2 (/32): 0x00000000 (dirty: 0, valid: 1)
(3) r3 (/32): 0x00000020 (dirty: 0, valid: 1)
(4) r4 (/32): 0xffffbfef (dirty: 0, valid: 1)
(5) r5 (/32): 0xffbfef00 (dirty: 0, valid: 1)
(6) r6 (/32): 0x4b1ab008 (dirty: 0, valid: 1)
(7) r7 (/32): 0x02255100 (dirty: 0, valid: 1)
(8) r8 (/32): 0xffffffff (dirty: 0, valid: 1)
(9) r9 (/32): 0xf7bfffff (dirty: 0, valid: 1)
(10) r10 (/32): 0xa1a5896d (dirty: 0, valid: 1)
(11) r11 (/32): 0x48fefd6d (dirty: 0, valid: 1)
(12) r12 (/32): 0xfdfdffff (dirty: 0, valid: 1)
(13) sp (/32): 0x2000ffa8 (dirty: 0, valid: 1)
(14) lr (/32): 0x200018df (dirty: 0, valid: 1)
(15) pc (/32): 0x20005005 (dirty: 1, valid: 1)
(16) xPSR (/32): 0xa1000025 (dirty: 0, valid: 1)
(17) msp (/32): 0x2000ffa8 (dirty: 0, valid: 1)
(18) psp (/32): 0x2000a000 (dirty: 0, valid: 1)
(19) primask (/32): 0x00000000 (dirty: 0, valid: 1)
(20) basepri (/32): 0x00000000 (dirty: 0, valid: 1)
(21) faultmask (/32): 0x00000000 (dirty: 0, valid: 1)
(22) control (/32): 0x00000000 (dirty: 0, valid: 1)
target state: halted
target halted in Thumb state due to single step, current mode: Handler 
External
Interrupt(21)
xPSR: 0xa1000025 pc: 0x200018de
SWJ-DP STICKY ERROR
dcb_dhcsr 0x103000f, nvic_shcsr 0x20000, nvic_cfsr 0x0, nvic_bfar 
0xe000edf8
SWJ-DP STICKY ERROR
dcb_dhcsr 0x3000f, nvic_shcsr 0x20000, nvic_cfsr 0x0, nvic_bfar 
0xe000edf8
Block read error address 0x225512c, count 0x1
unexpected error -107
SWJ-DP STICKY ERROR
dcb_dhcsr 0x3000f, nvic_shcsr 0x20000, nvic_cfsr 0x0, nvic_bfar 
0xe000edf8
SWJ-DP STICKY ERROR
dcb_dhcsr 0x3000f, nvic_shcsr 0x20000, nvic_cfsr 0x0, nvic_bfar 
0xe000edf8
Block read error address 0x225512c, count 0x1
unexpected error -107
SWJ-DP STICKY ERROR
dcb_dhcsr 0x3000f, nvic_shcsr 0x20000, nvic_cfsr 0x0, nvic_bfar 
0xe000edf8
SWJ-DP STICKY ERROR
dcb_dhcsr 0x3000f, nvic_shcsr 0x20000, nvic_cfsr 0x0, nvic_bfar 
0xe000edf8
Block read error address 0x225512c, count 0x1
unexpected error -107
SWJ-DP STICKY ERROR
dcb_dhcsr 0x3000f, nvic_shcsr 0x20000, nvic_cfsr 0x0, nvic_bfar 
0xe000edf8
SWJ-DP STICKY ERROR
dcb_dhcsr 0x3000f, nvic_shcsr 0x20000, nvic_cfsr 0x0, nvic_bfar 
0xe000edf8
Block read error address 0x225512c, count 0x1
unexpected error -107
> reg
(0) r0 (/32): 0x2000ffc4 (dirty: 1, valid: 1)
(1) r1 (/32): 0x4001040c (dirty: 0, valid: 1)
(2) r2 (/32): 0x00000000 (dirty: 0, valid: 1)
(3) r3 (/32): 0x00000020 (dirty: 0, valid: 1)
(4) r4 (/32): 0xffffbfef (dirty: 0, valid: 1)
(5) r5 (/32): 0xffbfef00 (dirty: 0, valid: 1)
(6) r6 (/32): 0x4b1ab008 (dirty: 0, valid: 1)
(7) r7 (/32): 0x02255100 (dirty: 0, valid: 1)
(8) r8 (/32): 0xffffffff (dirty: 0, valid: 1)
(9) r9 (/32): 0xf7bfffff (dirty: 0, valid: 1)
(10) r10 (/32): 0xa1a5896d (dirty: 0, valid: 1)
(11) r11 (/32): 0x48fefd6d (dirty: 0, valid: 1)
(12) r12 (/32): 0xfdfdffff (dirty: 0, valid: 1)
(13) sp (/32): 0x2000ffa8 (dirty: 0, valid: 1)
(14) lr (/32): 0x200018df (dirty: 0, valid: 1)
(15) pc (/32): 0x200018df (dirty: 1, valid: 1)
(16) xPSR (/32): 0xa1000025 (dirty: 0, valid: 1)
(17) msp (/32): 0x2000ffa8 (dirty: 0, valid: 1)
(18) psp (/32): 0x2000a000 (dirty: 0, valid: 1)
(19) primask (/32): 0x00000000 (dirty: 0, valid: 1)
(20) basepri (/32): 0x00000000 (dirty: 0, valid: 1)
(21) faultmask (/32): 0x00000000 (dirty: 0, valid: 1)
(22) control (/32): 0x00000000 (dirty: 0, valid: 1)
>

Author: Ar Lc (al2757)
Posted on:

Rate this post
0 useful
not useful
I've now compiled a new version of OpenOCD svn 2681.
  Now I'm looking inside the lst file,since I saw a problem in the 
disassembly window with the debuger the code corrupts my stack. I must 
say that things don't look the same now. It passes that issue with the 
"mov.w r7,0" but it corrupts my stack by having different instructions. 
Odd things are happening :-).

>LST file:
      *(__IO uint32_t *) tmp |= EXTI_InitStruct->EXTI_Line;
20004fca:  68f9        ldr  r1, [r7, #12]
20004fcc:  68fb        ldr  r3, [r7, #12]
20004fce:  681a        ldr  r2, [r3, #0]
20004fd0:  687b        ldr  r3, [r7, #4]
20004fd2:  681b        ldr  r3, [r3, #0]
20004fd4:  ea42 0303   orr.w  r3, r2, r3
20004fd8:  600b        str  r3, [r1, #0]
20004fda:  e00f        b.n  20004ffc <EXTI_Init+0x148>

>Disassembly window:

      *(__IO uint32_t *) tmp |= EXTI_InitStruct->EXTI_Line;
0x20004fca <EXTI_Init+278>: ldr   r1, [r7, #12]
0x20004fcc <EXTI_Init+280>: ldr   r3, [r7, #12]
0x20004fce <EXTI_Init+282>: ldr   r2, [r3, #0]
0x20004fd0 <EXTI_Init+284>: ldr   r3, [r7, #4]
0x20004fd2 <EXTI_Init+286>: ldr   r3, [r3, #0]
0x20004fd4 <EXTI_Init+288>: orr.w r3, r2, r3
>0x20004fd8 <EXTI_Init+292>: ldr   r7, [pc, #896]  (0x2000535c <GPIO_Init+208>)
>0x20004fda <EXTI_Init+294>: movs  r0, #0

It seems that my main.bin file is corrupted:
00004fd0: 7B 68 1B 68 42 EA 03 03 0B 60 0F......

Reply

Entering an e-mail address is optional. If you want to receive reply notifications by e-mail, please log in.

Rules — please read before posting

  • Post long source code as attachment, not in the text
  • Posting advertisements is forbidden.

Formatting options

  • [c]C code[/c]
  • [avrasm]AVR assembler code[/avrasm]
  • [code]code in other languages, ASCII drawings[/code]
  • [math]formula (LaTeX syntax)[/math]




Bild automatisch verkleinern, falls nötig
Note: the original post is older than 6 months. Please don't ask any new questions in this thread, but start a new one.