This is the mail archive of the
ecos-discuss@sourceware.org
mailing list for the eCos project.
Re: BLX raises an exception in cyg_start
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 <thepyper@gmail.com>:
> 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