From: Davide Pippa <thepyper@gmail.com>
To: ecos-discuss@sourceware.org
Subject: [ECOS] ecos on TWR-K70F120 "hangs" on startup in cyg_hal_invoke_constructors()
Date: Sat, 09 Feb 2013 11:19:00 -0000 [thread overview]
Message-ID: <511630B5.3010102@gmail.com> (raw)
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
next reply other threads:[~2013-02-09 11:19 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-09 11:19 Davide Pippa [this message]
2013-02-10 21:01 ` Ilija Kocho
[not found] ` <CAJuNW1M4EaYC4BSr171fKwtWZeZRgv4+41Bf=VFw24_F4g0XBw@mail.gmail.com>
2013-02-14 11:30 ` Davide Pippa
2013-02-14 11:42 ` Ilija Kocho
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=511630B5.3010102@gmail.com \
--to=thepyper@gmail.com \
--cc=ecos-discuss@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).