This is the mail archive of the ecos-discuss@sourceware.org mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]