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: Davide Pippa <thepyper at gmail dot com>
- To: ecos-discuss at sourceware dot org
- Date: Thu, 14 Feb 2013 12:29:27 +0100
- Subject: Re: [ECOS] ecos on TWR-K70F120 "hangs" on startup in cyg_hal_invoke_constructors()
- References: <511630B5.3010102@gmail.com> <51180AB0.9010707@siva.com.mk> <CAJuNW1M4EaYC4BSr171fKwtWZeZRgv4+41Bf=VFw24_F4g0XBw@mail.gmail.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