* [ECOS] ecos on TWR-K70F120 "hangs" on startup in cyg_hal_invoke_constructors()
@ 2013-02-09 11:19 Davide Pippa
2013-02-10 21:01 ` Ilija Kocho
0 siblings, 1 reply; 4+ messages in thread
From: Davide Pippa @ 2013-02-09 11:19 UTC (permalink / raw)
To: ecos-discuss
Hi!
I'm trying to make my first ecos app work on TWR-K70F120 board.
I've managed to get a toolchain work under cygwin (using the
"summon-arm-toolchain" script),
so my compiler version is "(Linaro GCC 4.6-2011.10) 4.6.2 20111004
(prerelease)".
I got openocd, ecos & tools compiled, and my application (which
currently does pretty nothing) as well.
I got the rom image loaded through openocd, using the usb osbdm jtag
on-board.
I managed to debug, step by step, the ecos startup, and everything seems
to go pretty well
until I enter the "cyg_hal_invoke_constructors()
".
Here, I see the loop of constructors being called (I looked at the code
in ecos\packages\hal\cortexm\arch\current\src\hal_misc.c, line 546 and
subsequent),
in the following loop:
...previous things in hal_reset_vsr()...
ca6: f000 f9b3 bl 1010 <hal_variant_init>
caa: f000 fa4f bl 114c <hal_platform_init>
cae: 4a21 ldr r2, [pc, #132] ; (d34
<hal_reset_vsr+0x16c>)
cb0: f248 531f movw r3, #34079 ; 0x851f
cb4: 6812 ldr r2, [r2, #0]
cb6: f2c5 13eb movt r3, #20971 ; 0x51eb
cba: fba3 1302 umull r1, r3, r3, r2
cbe: 4c1e ldr r4, [pc, #120] ; (d38
<hal_reset_vsr+0x170>)
cc0: 0959 lsrs r1, r3, #5
cc2: f24e 0214 movw r2, #57364 ; 0xe014
cc6: 3901 subs r1, #1
cc8: f2ce 0200 movt r2, #57344 ; 0xe000
ccc: f24e 0310 movw r3, #57360 ; 0xe010
cd0: 6011 str r1, [r2, #0]
cd2: f2ce 0300 movt r3, #57344 ; 0xe000
cd6: 2205 movs r2, #5
cd8: 42ac cmp r4, r5
cda: 601a str r2, [r3, #0]
cdc: d004 beq.n ce8 <hal_reset_vsr+0x120>
cde: f854 3b04 ldr.w r3, [r4], #4
ce2: 4798 blx r3
................................... HERE CONSTRUCTORS GET CALLED
..........................
ce4: 42ac cmp r4, r5
ce6: d1fa bne.n cde <hal_reset_vsr+0x116>
ce8: f001 f934 bl 1f54 <cyg_start>
cec: e7fe b.n cec <hal_reset_vsr+0x124>
cee: bf00 nop
What I see then is that on the second constructor being called,
everything hangs.
Being more specific, the second constructor being called is that:
000042fc <_GLOBAL__sub_I.11000_cyg_scheduler_sched_lock>:
42fc: b510 push {r4, lr}
42fe: f640 34cc movw r4, #3020 ; 0xbcc
4302: f2c7 0480 movt r4, #28800 ; 0x7080
4306: 4620 mov r0, r4
4308: f7ff fd50 bl 3dac
<_ZN28Cyg_Scheduler_ImplementationC1Ev>
430c: f244 01fd movw r1, #16637 ; 0x40fd
4310: f240 1214 movw r2, #276 ; 0x114
4314: 4620 mov r0, r4
4316: f2c0 0100 movt r1, #0
431a: f2c7 0280 movt r2, #28800 ; 0x7080
431e: e8bd 4010 ldmia.w sp!, {r4, lr}
4322: f00a bc35 b.w eb90 <____aeabi_atexit_from_thumb>
4326: bf00 nop
What I see tracing step by step is that I arrive at 0x4322, then I go
0xeb90 (that aeabi_etexit_from_thumb).
There I believe my application's destiny is cursed :) (am I wrong?),
anyway I go there:
0000eb90 <____aeabi_atexit_from_thumb>:
eb90: 4778 bx pc
eb92: 46c0 nop ; (mov r8, r8)
eb94: eafffff5 b eb70 <__aeabi_atexit>
Here, what happens is that if I continue debugging, step arrives until
0xeb94, then everything hangs.
By hangs, I mean I get sticky errors, and the only thing I may then do
is a "reset halt" thing.
Here is a debug session test with openocd:
> reset halt
Info : JTAG tap: k70.cpu tap/device found: 0x4ba00477 (mfg: 0x23b,
part: 0xba00
, ver: 0x4)
JTAG tap: k70.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part:
0xba00, ver: 0
x4)START...
END...
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x
00000bc8 msp: 0x20010000target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x00000bc8 msp: 0x20010000
>
>
> bp 0xeb90 4
breakpoint set at 0x0000eb90
breakpoint set at 0x0000eb90
> resume
> target state: halted
target halted due to breakpoint, current mode: Thread
xPSR: 0x21000000 pc: 0x0000eb90 psp: 0x2000fff0
target state: halted
target halted due to breakpoint, current mode: Thread
xPSR: 0x21000000 pc: 0x0000eb90 psp: 0x2000fff0
> rbp 0xeb90
> step
target state: halted
target halted due to single-step, current mode: Thread
xPSR: 0x20000000 pc: 0x00
00eb94 psp: 0x2000fff0target state: halted
target halted due to single-step, current mode: Thread
xPSR: 0x20000000 pc: 0x0000eb94 psp: 0x2000fff0
> step
Error: JTAG-DP STICKY ERROR
JTAG-DP STICKY ERROR
Error: MEM_AP_CSW 0x23000042, MEM_AP_TAR 0xe000edf0
MEM_AP_CSW 0x23000042, MEM_AP_TAR 0xe000edf0
in procedure 'step'
in procedure 'step'
> Error: JTAG-DP STICKY ERROR
JTAG-DP STICKY ERROR
> Error: MEM_AP_CSW 0x23000042, MEM_AP_TAR 0xe000edf0
Polling target failed, GDB will be halted. Polling again in 100ms
MEM_AP_CSW 0x23
000042, MEM_AP_TAR 0xe000edf0
Polling target failed, GDB will be halted. Polling again in 100ms
> Polling succeeded again
Polling succeeded again
> Error: JTAG-DP STICKY ERROR
JTAG-DP STICKY ERROR
> Error: MEM_AP_CSW 0x23000042, MEM_AP_TAR 0xe000edf0
Polling target failed, GDB will be halted. Polling again in 100ms
MEM_AP_CSW 0x23000042, MEM_AP_TAR 0xe000edf0
Polling target failed, GDB will be halted. Polling again in 100ms
> Polling succeeded again
Polling succeeded again
> reset haError: JTAG-DP STICKY ERROR
JTAG-DP STICKY ERROR
Error: > reset haMEM_AP_CSW 0x23000042, MEM_AP_TAR 0xe000edf0
Polling target failed, GDB will be halted. Polling again in 100ms
MEM_AP_CSW 0x23000042
, MEM_AP_TAR 0xe000edf0
Polling target failed, GDB will be halted. Polling again in 100ms
> reset haltPolling succeeded again
Polling succeeded again
> reset halt
Info : JTAG tap: k70.cpu tap/device found: 0x4ba00477 (mfg: 0x23b,
part: 0xba00
, ver: 0x4)
JTAG tap: k70.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part:
0xba00, ver: 0
x4)START...
END...
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x
00000bc8 msp: 0x20010000target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x00000bc8 msp: 0x20010000
>
My question then is, where should I look for the source code of that
constructor ?
Is that compiler-generated or are those hand-made constructors that I
can look for?
Anybody has an idea of why that constructor is failing, and if it
actually is failing?
Another thing I haven't still found is where the
CYGSEM_HAL_STOP_CONSTRUCTORS_ON_FLAG is defined,
and how I can be sure to remove it with configurator; I wonder if what
I'm seeing is just that the constructor is
somehow not setting "cyg_hal_stop_constructors" and then "correctly
hanging system"?
Thanks for any help :)
Pyper
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [ECOS] ecos on TWR-K70F120 "hangs" on startup in cyg_hal_invoke_constructors()
2013-02-09 11:19 [ECOS] ecos on TWR-K70F120 "hangs" on startup in cyg_hal_invoke_constructors() Davide Pippa
@ 2013-02-10 21:01 ` Ilija Kocho
[not found] ` <CAJuNW1M4EaYC4BSr171fKwtWZeZRgv4+41Bf=VFw24_F4g0XBw@mail.gmail.com>
0 siblings, 1 reply; 4+ messages in thread
From: Ilija Kocho @ 2013-02-10 21:01 UTC (permalink / raw)
To: Davide Pippa; +Cc: ecos-discuss
Hi Davide
The constructors are initialization functions (such as devices, etc),
not compiler generated. In your case probably system is trying to
initialize some device that is not present. It would help if you send
your configuration. Typically this is done by generation of ECM file
(File->Export).
Regarding tools, you might want to try eCos gnutools 4.6.3. Here you
will find information for download and installation.
http://ecos.sourceware.org/ml/ecos-discuss/2012-06/msg00047.html
Ilija
On 09.02.2013 12:19, Davide Pippa wrote:
> Hi!
>
> I'm trying to make my first ecos app work on TWR-K70F120 board.
> I've managed to get a toolchain work under cygwin (using the
> "summon-arm-toolchain" script),
> so my compiler version is "(Linaro GCC 4.6-2011.10) 4.6.2 20111004
> (prerelease)".
> I got openocd, ecos & tools compiled, and my application (which
> currently does pretty nothing) as well.
> I got the rom image loaded through openocd, using the usb osbdm jtag
> on-board.
> I managed to debug, step by step, the ecos startup, and everything
> seems to go pretty well
> until I enter the "cyg_hal_invoke_constructors()
> ".
> Here, I see the loop of constructors being called (I looked at the
> code in ecos\packages\hal\cortexm\arch\current\src\hal_misc.c, line
> 546 and subsequent),
> in the following loop:
>
> ...previous things in hal_reset_vsr()...
> ca6: f000 f9b3 bl 1010 <hal_variant_init>
> caa: f000 fa4f bl 114c <hal_platform_init>
> cae: 4a21 ldr r2, [pc, #132] ; (d34
> <hal_reset_vsr+0x16c>)
> cb0: f248 531f movw r3, #34079 ; 0x851f
> cb4: 6812 ldr r2, [r2, #0]
> cb6: f2c5 13eb movt r3, #20971 ; 0x51eb
> cba: fba3 1302 umull r1, r3, r3, r2
> cbe: 4c1e ldr r4, [pc, #120] ; (d38
> <hal_reset_vsr+0x170>)
> cc0: 0959 lsrs r1, r3, #5
> cc2: f24e 0214 movw r2, #57364 ; 0xe014
> cc6: 3901 subs r1, #1
> cc8: f2ce 0200 movt r2, #57344 ; 0xe000
> ccc: f24e 0310 movw r3, #57360 ; 0xe010
> cd0: 6011 str r1, [r2, #0]
> cd2: f2ce 0300 movt r3, #57344 ; 0xe000
> cd6: 2205 movs r2, #5
> cd8: 42ac cmp r4, r5
> cda: 601a str r2, [r3, #0]
> cdc: d004 beq.n ce8 <hal_reset_vsr+0x120>
> cde: f854 3b04 ldr.w r3, [r4], #4
> ce2: 4798 blx r3
> ................................... HERE CONSTRUCTORS GET CALLED
> ..........................
> ce4: 42ac cmp r4, r5
> ce6: d1fa bne.n cde <hal_reset_vsr+0x116>
> ce8: f001 f934 bl 1f54 <cyg_start>
> cec: e7fe b.n cec <hal_reset_vsr+0x124>
> cee: bf00 nop
>
> What I see then is that on the second constructor being called,
> everything hangs.
> Being more specific, the second constructor being called is that:
>
> 000042fc <_GLOBAL__sub_I.11000_cyg_scheduler_sched_lock>:
> 42fc: b510 push {r4, lr}
> 42fe: f640 34cc movw r4, #3020 ; 0xbcc
> 4302: f2c7 0480 movt r4, #28800 ; 0x7080
> 4306: 4620 mov r0, r4
> 4308: f7ff fd50 bl 3dac
> <_ZN28Cyg_Scheduler_ImplementationC1Ev>
> 430c: f244 01fd movw r1, #16637 ; 0x40fd
> 4310: f240 1214 movw r2, #276 ; 0x114
> 4314: 4620 mov r0, r4
> 4316: f2c0 0100 movt r1, #0
> 431a: f2c7 0280 movt r2, #28800 ; 0x7080
> 431e: e8bd 4010 ldmia.w sp!, {r4, lr}
> 4322: f00a bc35 b.w eb90 <____aeabi_atexit_from_thumb>
> 4326: bf00 nop
>
> What I see tracing step by step is that I arrive at 0x4322, then I go
> 0xeb90 (that aeabi_etexit_from_thumb).
> There I believe my application's destiny is cursed :) (am I wrong?),
> anyway I go there:
>
> 0000eb90 <____aeabi_atexit_from_thumb>:
> eb90: 4778 bx pc
> eb92: 46c0 nop ; (mov r8, r8)
> eb94: eafffff5 b eb70 <__aeabi_atexit>
>
> Here, what happens is that if I continue debugging, step arrives until
> 0xeb94, then everything hangs.
> By hangs, I mean I get sticky errors, and the only thing I may then do
> is a "reset halt" thing.
> Here is a debug session test with openocd:
>
> > reset halt
> Info : JTAG tap: k70.cpu tap/device found: 0x4ba00477 (mfg: 0x23b,
> part: 0xba00
> , ver: 0x4)
> JTAG tap: k70.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part:
> 0xba00, ver: 0
> x4)START...
>
> END...
> target state: halted
> target halted due to debug-request, current mode: Thread
> xPSR: 0x01000000 pc: 0x
> 00000bc8 msp: 0x20010000target state: halted
>
> target halted due to debug-request, current mode: Thread
> xPSR: 0x01000000 pc: 0x00000bc8 msp: 0x20010000
> >
> >
> > bp 0xeb90 4
> breakpoint set at 0x0000eb90
> breakpoint set at 0x0000eb90
> > resume
> > target state: halted
> target halted due to breakpoint, current mode: Thread
> xPSR: 0x21000000 pc: 0x0000eb90 psp: 0x2000fff0
> target state: halted
> target halted due to breakpoint, current mode: Thread
> xPSR: 0x21000000 pc: 0x0000eb90 psp: 0x2000fff0
> > rbp 0xeb90
> > step
> target state: halted
> target halted due to single-step, current mode: Thread
> xPSR: 0x20000000 pc: 0x00
> 00eb94 psp: 0x2000fff0target state: halted
>
> target halted due to single-step, current mode: Thread
> xPSR: 0x20000000 pc: 0x0000eb94 psp: 0x2000fff0
> > step
> Error: JTAG-DP STICKY ERROR
> JTAG-DP STICKY ERROR
> Error: MEM_AP_CSW 0x23000042, MEM_AP_TAR 0xe000edf0
> MEM_AP_CSW 0x23000042, MEM_AP_TAR 0xe000edf0
> in procedure 'step'
> in procedure 'step'
> > Error: JTAG-DP STICKY ERROR
> JTAG-DP STICKY ERROR
> > Error: MEM_AP_CSW 0x23000042, MEM_AP_TAR 0xe000edf0
> Polling target failed, GDB will be halted. Polling again in 100ms
> MEM_AP_CSW 0x23
> 000042, MEM_AP_TAR 0xe000edf0
> Polling target failed, GDB will be halted. Polling again in 100ms
> > Polling succeeded again
> Polling succeeded again
> > Error: JTAG-DP STICKY ERROR
> JTAG-DP STICKY ERROR
> > Error: MEM_AP_CSW 0x23000042, MEM_AP_TAR 0xe000edf0
> Polling target failed, GDB will be halted. Polling again in 100ms
> MEM_AP_CSW 0x23000042, MEM_AP_TAR 0xe000edf0
> Polling target failed, GDB will be halted. Polling again in 100ms
> > Polling succeeded again
> Polling succeeded again
> > reset haError: JTAG-DP STICKY ERROR
> JTAG-DP STICKY ERROR
> Error: > reset haMEM_AP_CSW 0x23000042, MEM_AP_TAR 0xe000edf0
> Polling target failed, GDB will be halted. Polling again in 100ms
> MEM_AP_CSW 0x23000042
> , MEM_AP_TAR 0xe000edf0
> Polling target failed, GDB will be halted. Polling again in 100ms
> > reset haltPolling succeeded again
> Polling succeeded again
> > reset halt
> Info : JTAG tap: k70.cpu tap/device found: 0x4ba00477 (mfg: 0x23b,
> part: 0xba00
> , ver: 0x4)
> JTAG tap: k70.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part:
> 0xba00, ver: 0
> x4)START...
>
> END...
> target state: halted
> target halted due to debug-request, current mode: Thread
> xPSR: 0x01000000 pc: 0x
> 00000bc8 msp: 0x20010000target state: halted
>
> target halted due to debug-request, current mode: Thread
> xPSR: 0x01000000 pc: 0x00000bc8 msp: 0x20010000
> >
>
> My question then is, where should I look for the source code of that
> constructor ?
> Is that compiler-generated or are those hand-made constructors that I
> can look for?
> Anybody has an idea of why that constructor is failing, and if it
> actually is failing?
>
> Another thing I haven't still found is where the
> CYGSEM_HAL_STOP_CONSTRUCTORS_ON_FLAG is defined,
> and how I can be sure to remove it with configurator; I wonder if what
> I'm seeing is just that the constructor is
> somehow not setting "cyg_hal_stop_constructors" and then "correctly
> hanging system"?
>
> Thanks for any help :)
>
> Pyper
>
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [ECOS] ecos on TWR-K70F120 "hangs" on startup in cyg_hal_invoke_constructors()
[not found] ` <CAJuNW1M4EaYC4BSr171fKwtWZeZRgv4+41Bf=VFw24_F4g0XBw@mail.gmail.com>
@ 2013-02-14 11:30 ` Davide Pippa
2013-02-14 11:42 ` Ilija Kocho
0 siblings, 1 reply; 4+ messages in thread
From: Davide Pippa @ 2013-02-14 11:30 UTC (permalink / raw)
To: ecos-discuss
Thanks for the help!
I just tried to compile things with the eCos Gnutools 4.6.3, and things
seems to behave better,
as I can go further with my debugging session, to the point that I get into
"cyg_start", and even more.
Still cannot get into my main() function, but I get no sticky errors at all
and I just need to debug
further to see what I'm missing...
A question: does that compiler support hardware floating point for
cortex-m4?
Thanks! :)
2013/2/10 Ilija Kocho <ilija.kocho@gmail.com>
>
> Hi Davide
>
> The constructors are initialization functions (such as devices, etc),
> not compiler generated. In your case probably system is trying to
> initialize some device that is not present. It would help if you send
> your configuration. Typically this is done by generation of ECM file
> (File->Export).
>
> Regarding tools, you might want to try eCos gnutools 4.6.3. Here you
> will find information for download and installation.
> http://ecos.sourceware.org/ml/ecos-discuss/2012-06/msg00047.html
>
> Ilija
>
> On 09.02.2013 12:19, Davide Pippa wrote:
> > Hi!
> >
> > I'm trying to make my first ecos app work on TWR-K70F120 board.
> > I've managed to get a toolchain work under cygwin (using the
> > "summon-arm-toolchain" script),
> > so my compiler version is "(Linaro GCC 4.6-2011.10) 4.6.2 20111004
> > (prerelease)".
> > I got openocd, ecos & tools compiled, and my application (which
> > currently does pretty nothing) as well.
> > I got the rom image loaded through openocd, using the usb osbdm jtag
> > on-board.
> > I managed to debug, step by step, the ecos startup, and everything
> > seems to go pretty well
> > until I enter the "cyg_hal_invoke_constructors()
> > ".
> > Here, I see the loop of constructors being called (I looked at the
> > code in ecos\packages\hal\cortexm\arch\current\src\hal_misc.c, line
> > 546 and subsequent),
> > in the following loop:
> >
> > ...previous things in hal_reset_vsr()...
> > ca6: f000 f9b3 bl 1010 <hal_variant_init>
> > caa: f000 fa4f bl 114c <hal_platform_init>
> > cae: 4a21 ldr r2, [pc, #132] ; (d34
> > <hal_reset_vsr+0x16c>)
> > cb0: f248 531f movw r3, #34079 ; 0x851f
> > cb4: 6812 ldr r2, [r2, #0]
> > cb6: f2c5 13eb movt r3, #20971 ; 0x51eb
> > cba: fba3 1302 umull r1, r3, r3, r2
> > cbe: 4c1e ldr r4, [pc, #120] ; (d38
> > <hal_reset_vsr+0x170>)
> > cc0: 0959 lsrs r1, r3, #5
> > cc2: f24e 0214 movw r2, #57364 ; 0xe014
> > cc6: 3901 subs r1, #1
> > cc8: f2ce 0200 movt r2, #57344 ; 0xe000
> > ccc: f24e 0310 movw r3, #57360 ; 0xe010
> > cd0: 6011 str r1, [r2, #0]
> > cd2: f2ce 0300 movt r3, #57344 ; 0xe000
> > cd6: 2205 movs r2, #5
> > cd8: 42ac cmp r4, r5
> > cda: 601a str r2, [r3, #0]
> > cdc: d004 beq.n ce8 <hal_reset_vsr+0x120>
> > cde: f854 3b04 ldr.w r3, [r4], #4
> > ce2: 4798 blx r3
> > ................................... HERE CONSTRUCTORS GET CALLED
> > ..........................
> > ce4: 42ac cmp r4, r5
> > ce6: d1fa bne.n cde <hal_reset_vsr+0x116>
> > ce8: f001 f934 bl 1f54 <cyg_start>
> > cec: e7fe b.n cec <hal_reset_vsr+0x124>
> > cee: bf00 nop
> >
> > What I see then is that on the second constructor being called,
> > everything hangs.
> > Being more specific, the second constructor being called is that:
> >
> > 000042fc <_GLOBAL__sub_I.11000_cyg_scheduler_sched_lock>:
> > 42fc: b510 push {r4, lr}
> > 42fe: f640 34cc movw r4, #3020 ; 0xbcc
> > 4302: f2c7 0480 movt r4, #28800 ; 0x7080
> > 4306: 4620 mov r0, r4
> > 4308: f7ff fd50 bl 3dac
> > <_ZN28Cyg_Scheduler_ImplementationC1Ev>
> > 430c: f244 01fd movw r1, #16637 ; 0x40fd
> > 4310: f240 1214 movw r2, #276 ; 0x114
> > 4314: 4620 mov r0, r4
> > 4316: f2c0 0100 movt r1, #0
> > 431a: f2c7 0280 movt r2, #28800 ; 0x7080
> > 431e: e8bd 4010 ldmia.w sp!, {r4, lr}
> > 4322: f00a bc35 b.w eb90 <____aeabi_atexit_from_thumb>
> > 4326: bf00 nop
> >
> > What I see tracing step by step is that I arrive at 0x4322, then I go
> > 0xeb90 (that aeabi_etexit_from_thumb).
> > There I believe my application's destiny is cursed :) (am I wrong?),
> > anyway I go there:
> >
> > 0000eb90 <____aeabi_atexit_from_thumb>:
> > eb90: 4778 bx pc
> > eb92: 46c0 nop ; (mov r8, r8)
> > eb94: eafffff5 b eb70 <__aeabi_atexit>
> >
> > Here, what happens is that if I continue debugging, step arrives until
> > 0xeb94, then everything hangs.
> > By hangs, I mean I get sticky errors, and the only thing I may then do
> > is a "reset halt" thing.
> > Here is a debug session test with openocd:
> >
> > > reset halt
> > Info : JTAG tap: k70.cpu tap/device found: 0x4ba00477 (mfg: 0x23b,
> > part: 0xba00
> > , ver: 0x4)
> > JTAG tap: k70.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part:
> > 0xba00, ver: 0
> > x4)START...
> >
> > END...
> > target state: halted
> > target halted due to debug-request, current mode: Thread
> > xPSR: 0x01000000 pc: 0x
> > 00000bc8 msp: 0x20010000target state: halted
> >
> > target halted due to debug-request, current mode: Thread
> > xPSR: 0x01000000 pc: 0x00000bc8 msp: 0x20010000
> > >
> > >
> > > bp 0xeb90 4
> > breakpoint set at 0x0000eb90
> > breakpoint set at 0x0000eb90
> > > resume
> > > target state: halted
> > target halted due to breakpoint, current mode: Thread
> > xPSR: 0x21000000 pc: 0x0000eb90 psp: 0x2000fff0
> > target state: halted
> > target halted due to breakpoint, current mode: Thread
> > xPSR: 0x21000000 pc: 0x0000eb90 psp: 0x2000fff0
> > > rbp 0xeb90
> > > step
> > target state: halted
> > target halted due to single-step, current mode: Thread
> > xPSR: 0x20000000 pc: 0x00
> > 00eb94 psp: 0x2000fff0target state: halted
> >
> > target halted due to single-step, current mode: Thread
> > xPSR: 0x20000000 pc: 0x0000eb94 psp: 0x2000fff0
> > > step
> > Error: JTAG-DP STICKY ERROR
> > JTAG-DP STICKY ERROR
> > Error: MEM_AP_CSW 0x23000042, MEM_AP_TAR 0xe000edf0
> > MEM_AP_CSW 0x23000042, MEM_AP_TAR 0xe000edf0
> > in procedure 'step'
> > in procedure 'step'
> > > Error: JTAG-DP STICKY ERROR
> > JTAG-DP STICKY ERROR
> > > Error: MEM_AP_CSW 0x23000042, MEM_AP_TAR 0xe000edf0
> > Polling target failed, GDB will be halted. Polling again in 100ms
> > MEM_AP_CSW 0x23
> > 000042, MEM_AP_TAR 0xe000edf0
> > Polling target failed, GDB will be halted. Polling again in 100ms
> > > Polling succeeded again
> > Polling succeeded again
> > > Error: JTAG-DP STICKY ERROR
> > JTAG-DP STICKY ERROR
> > > Error: MEM_AP_CSW 0x23000042, MEM_AP_TAR 0xe000edf0
> > Polling target failed, GDB will be halted. Polling again in 100ms
> > MEM_AP_CSW 0x23000042, MEM_AP_TAR 0xe000edf0
> > Polling target failed, GDB will be halted. Polling again in 100ms
> > > Polling succeeded again
> > Polling succeeded again
> > > reset haError: JTAG-DP STICKY ERROR
> > JTAG-DP STICKY ERROR
> > Error: > reset haMEM_AP_CSW 0x23000042, MEM_AP_TAR 0xe000edf0
> > Polling target failed, GDB will be halted. Polling again in 100ms
> > MEM_AP_CSW 0x23000042
> > , MEM_AP_TAR 0xe000edf0
> > Polling target failed, GDB will be halted. Polling again in 100ms
> > > reset haltPolling succeeded again
> > Polling succeeded again
> > > reset halt
> > Info : JTAG tap: k70.cpu tap/device found: 0x4ba00477 (mfg: 0x23b,
> > part: 0xba00
> > , ver: 0x4)
> > JTAG tap: k70.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part:
> > 0xba00, ver: 0
> > x4)START...
> >
> > END...
> > target state: halted
> > target halted due to debug-request, current mode: Thread
> > xPSR: 0x01000000 pc: 0x
> > 00000bc8 msp: 0x20010000target state: halted
> >
> > target halted due to debug-request, current mode: Thread
> > xPSR: 0x01000000 pc: 0x00000bc8 msp: 0x20010000
> > >
> >
> > My question then is, where should I look for the source code of that
> > constructor ?
> > Is that compiler-generated or are those hand-made constructors that I
> > can look for?
> > Anybody has an idea of why that constructor is failing, and if it
> > actually is failing?
> >
> > Another thing I haven't still found is where the
> > CYGSEM_HAL_STOP_CONSTRUCTORS_ON_FLAG is defined,
> > and how I can be sure to remove it with configurator; I wonder if what
> > I'm seeing is just that the constructor is
> > somehow not setting "cyg_hal_stop_constructors" and then "correctly
> > hanging system"?
> >
> > Thanks for any help :)
> >
> > Pyper
> >
>
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [ECOS] ecos on TWR-K70F120 "hangs" on startup in cyg_hal_invoke_constructors()
2013-02-14 11:30 ` Davide Pippa
@ 2013-02-14 11:42 ` Ilija Kocho
0 siblings, 0 replies; 4+ messages in thread
From: Ilija Kocho @ 2013-02-14 11:42 UTC (permalink / raw)
To: Davide Pippa; +Cc: ecos-discuss
On 14.02.2013 12:29, Davide Pippa wrote:
> Thanks for the help!
>
> I just tried to compile things with the eCos Gnutools 4.6.3, and things
> seems to behave better,
> as I can go further with my debugging session, to the point that I get into
> "cyg_start", and even more.
> Still cannot get into my main() function, but I get no sticky errors at all
> and I just need to debug
> further to see what I'm missing...
> A question: does that compiler support hardware floating point for
> cortex-m4?
Sure. You can even see VFP floating point registers with GDB 7.4.1 that
comes with eCos Gnutools 4.6.3 provided that GDB server supports them.
Only, for the time being eCos floating point support is not yet
committed to CVS so you shall have to apply the patches from eCos'
Bugzilla http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001607
I will appreciate feedback.
Ilija
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2013-02-14 11:42 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-02-09 11:19 [ECOS] ecos on TWR-K70F120 "hangs" on startup in cyg_hal_invoke_constructors() Davide Pippa
2013-02-10 21:01 ` Ilija Kocho
[not found] ` <CAJuNW1M4EaYC4BSr171fKwtWZeZRgv4+41Bf=VFw24_F4g0XBw@mail.gmail.com>
2013-02-14 11:30 ` Davide Pippa
2013-02-14 11:42 ` Ilija Kocho
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).