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
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_projects/arm_memcards/index.html#chanfat_stm32 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.
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).
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
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
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"
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) >
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......
Watch this topic
Disable multi-page viewPlease log in before posting. Registration is free and takes only a minute.
Existing account
Do you have a Google/GoogleMail account? No registration required!
Log in with Google account
Log in with Google account
No account? Register here.