From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12344 invoked by alias); 14 Feb 2013 11:30:00 -0000 Received: (qmail 12332 invoked by uid 22791); 14 Feb 2013 11:29:59 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,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-wi0-f175.google.com (HELO mail-wi0-f175.google.com) (209.85.212.175) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 14 Feb 2013 11:29:49 +0000 Received: by mail-wi0-f175.google.com with SMTP id l13so6884353wie.14 for ; Thu, 14 Feb 2013 03:29:47 -0800 (PST) X-Received: by 10.180.80.74 with SMTP id p10mr16257282wix.19.1360841387325; Thu, 14 Feb 2013 03:29:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.194.41.170 with HTTP; Thu, 14 Feb 2013 03:29:27 -0800 (PST) In-Reply-To: References: <511630B5.3010102@gmail.com> <51180AB0.9010707@siva.com.mk> From: Davide Pippa Date: Thu, 14 Feb 2013 11:30:00 -0000 Message-ID: To: ecos-discuss@sourceware.org Content-Type: text/plain; charset=ISO-8859-1 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/msg00012.txt.bz2 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 > > 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