This is the mail archive of the
ecos-discuss@sourceware.org
mailing list for the eCos project.
Re: ecos on TWR-K70F120 "hangs" on startup in cyg_hal_invoke_constructors()
- From: Ilija Kocho <ilija dot kocho at gmail dot com>
- To: Davide Pippa <thepyper at gmail dot com>
- Cc: ecos-discuss at sourceware dot org
- Date: Sun, 10 Feb 2013 22:01:36 +0100
- Subject: Re: [ECOS] ecos on TWR-K70F120 "hangs" on startup in cyg_hal_invoke_constructors()
- References: <511630B5.3010102@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