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
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 view