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

[Davide Pippa <thepyper at gmail dot com>]

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