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.ko...@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
