From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10170 invoked by alias); 9 Feb 2013 11:19:29 -0000 Received: (qmail 10161 invoked by uid 22791); 9 Feb 2013 11:19:29 -0000 X-SWARE-Spam-Status: No, hits=-4.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,KHOP_RCVD_TRUST,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-ee0-f54.google.com (HELO mail-ee0-f54.google.com) (74.125.83.54) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 09 Feb 2013 11:19:22 +0000 Received: by mail-ee0-f54.google.com with SMTP id c41so2522123eek.13 for ; Sat, 09 Feb 2013 03:19:21 -0800 (PST) X-Received: by 10.14.219.5 with SMTP id l5mr26834536eep.7.1360408760929; Sat, 09 Feb 2013 03:19:20 -0800 (PST) Received: from [192.168.1.27] ([93.37.222.143]) by mx.google.com with ESMTPS id q42sm42577749eem.14.2013.02.09.03.19.20 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 09 Feb 2013 03:19:20 -0800 (PST) Message-ID: <511630B5.3010102@gmail.com> Date: Sat, 09 Feb 2013 11:19:00 -0000 From: Davide Pippa User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: ecos-discuss@sourceware.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed 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: [ECOS] ecos on TWR-K70F120 "hangs" on startup in cyg_hal_invoke_constructors() X-SW-Source: 2013-02/txt/msg00009.txt.bz2 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