Sorry I have found the problem! I was compilinig my application (that single-line main) with wrong cpu flags (default, then I suppose non-cortex-m and non-thumb), then I got a (malformed?) blx; adding correct flags to my application compilation got it right now, and I'm getting into cyg_user_start.
Davide 2013/2/16 Davide Pippa <[email protected]>: > Hi! > > I'm still trying to get my first application run with eCos, on > TWR-K70F120M board. > I've got it compiling, and debugging thru openocd. I'm now using eCos > gnutools 4.6.3 > for compilation, now my problem is that everything seems ok, but my > main() function > never gets called. > I've seen there is no reference to in in the whole disassembled image, I > suppose > then the "hello world" tutorial in the docs is outdated? > > I've tried changing main() into cyg_user_start(). > Then I see a change, as in cyg_start() I see a cyg_user_start() call: > > 00001f64 <cyg_start>: > 1f64: b508 push {r3, lr} > 1f66: f000 f807 bl 1f78 <cyg_prestart> > 1f6a: f000 f807 bl 1f7c <cyg_package_start> > 1f6e: f7fe eab0 blx 4d0 <cyg_user_start> > 1f72: f002 f9b7 bl 42e4 <_ZN13Cyg_Scheduler5startEv> > 1f76: bf00 nop > > My problem now is that when I hit that "blx 4d0" line, instead of > correctly going into cyg_user_start at 0x4d0, > things go there: > > 0000043c <hal_default_exception_vsr>: > 43c: f3ef 8009 mrs r0, PSP > 440: f1a0 0130 sub.w r1, r0, #48 ; 0x30 > 444: f381 8809 msr PSP, r1 > 448: f04f 0101 mov.w r1, #1 > 44c: f3ef 8205 mrs r2, IPSR > 450: f3ef 8311 mrs r3, BASEPRI > 454: e920 4ffe stmdb r0!, {r1, r2, r3, r4, r5, r6, r7, r8, > r9, sl, fp, lr} > 458: 4604 mov r4, r0 > 45a: f000 fc65 bl d28 <hal_deliver_exception> > 45e: 4620 mov r0, r4 > 460: e8b0 4ffe ldmia.w r0!, {r1, r2, r3, r4, r5, r6, r7, r8, > r9, > sl, fp, lr} > 464: f380 8809 msr PSP, r0 > 468: f383 8811 msr BASEPRI, r3 > 46c: 4770 bx lr > > And i get, into openocd, a message that indicates that an exception has risen; > here is a debug session: > > ... reset halt thing ... > >> bp 0x1f6e 4 > breakpoint set at 0x00001f6e > breakpoint set at 0x00001f6e >> resume >> target state: halted > target halted due to breakpoint, current mode: Thread > xPSR: 0x61000000 pc: 0x00001f6e psp: 0x2000ffe8 > target state: halted > target halted due to breakpoint, current mode: Thread > xPSR: 0x61000000 pc: 0x00001f6e psp: 0x2000ffe8 >> rbp 0x1f6e >> step > target state: halted > target halted due to single-step, current mode: Handler UsageFault > xPSR: > 0x610000 > 06 pc: 0x0000043c msp: 0x2000ffd0target state: halted > > target halted due to single-step, current mode: Handler UsageFault > xPSR: 0x61000006 pc: 0x0000043c msp: 0x2000ffd0 >> > > I see "current mode" going to Handles UsageFault. > > I looked into cortex-m architecture reference manual, and seen that "blx" > can raise such an exception. Anybody has any clue on what is happening? > > Another thing I cannot understand is that: I see that line in disassembly: > > 1f6e: f7fe eab0 blx 4d0 <cyg_user_start> > > that seems to indicate a 32bit-encoded instruction, but on the Arm-M > Reference Manual > I can only find a 16-bit encoded "BLX" instruction, being referred to > a register, not > to an absolute / relative jump. Is that a mis-disassembly? Or am I > missing something? > > I've tried compiling eCos in 2 configurations, the first using > defaults (twr-k70f120m with lwip stack), > the second changing compile flags to have -mcpu=cortex-m4 instead oc > -mcpu=cortex-m3; > anyway, the "BLX" problem happens... > > 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
