ecos on TWR-K70F120 "hangs" on startup in cyg_hal_invoke_constructors()

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

ecos on TWR-K70F120 "hangs" on startup in cyg_hal_invoke_constructors()

Davide Pippa
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

Reply | Threaded
Open this post in threaded view
|

Re: ecos on TWR-K70F120 "hangs" on startup in cyg_hal_invoke_constructors()

Ilija Kocho-2
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

Reply | Threaded
Open this post in threaded view
|

Re: ecos on TWR-K70F120 "hangs" on startup in cyg_hal_invoke_constructors()

Davide Pippa
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 <[hidden email]>

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

Reply | Threaded
Open this post in threaded view
|

Re: ecos on TWR-K70F120 "hangs" on startup in cyg_hal_invoke_constructors()

Ilija Kocho [Илија Кочо]
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