This is the mail archive of the ecos-discuss@sourceware.org mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]