From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22633 invoked by alias); 10 Feb 2013 21:01:53 -0000 Received: (qmail 22614 invoked by uid 22791); 10 Feb 2013 21:01:52 -0000 X-SWARE-Spam-Status: No, hits=-5.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,KHOP_RCVD_TRUST,KHOP_THREADED,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE,TW_BD,TW_BL,TW_OV,TW_XB X-Spam-Check-By: sourceware.org Received: from mail-bk0-f48.google.com (HELO mail-bk0-f48.google.com) (209.85.214.48) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 10 Feb 2013 21:01:41 +0000 Received: by mail-bk0-f48.google.com with SMTP id jf20so2382142bkc.35 for ; Sun, 10 Feb 2013 13:01:40 -0800 (PST) X-Received: by 10.204.130.22 with SMTP id q22mr2565896bks.44.1360530100015; Sun, 10 Feb 2013 13:01:40 -0800 (PST) Received: from [192.168.178.35] ([77.28.172.95]) by mx.google.com with ESMTPS id g28sm12484536bkv.17.2013.02.10.13.01.38 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 10 Feb 2013 13:01:39 -0800 (PST) Message-ID: <51180AB0.9010707@siva.com.mk> Date: Sun, 10 Feb 2013 21:01:00 -0000 From: Ilija Kocho User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Davide Pippa CC: ecos-discuss@sourceware.org References: <511630B5.3010102@gmail.com> In-Reply-To: <511630B5.3010102@gmail.com> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Mailing-List: contact ecos-discuss-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: ecos-discuss-owner@ecos.sourceware.org Subject: Re: [ECOS] ecos on TWR-K70F120 "hangs" on startup in cyg_hal_invoke_constructors() X-SW-Source: 2013-02/txt/msg00011.txt.bz2 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 > caa: f000 fa4f bl 114c > cae: 4a21 ldr r2, [pc, #132] ; (d34 > ) > 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 > ) > 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 > 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 > ce8: f001 f934 bl 1f54 > cec: e7fe b.n cec > 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