RTEMS_FATAL_SOURCE_EXCEPTION during startup

Петр Борисенко peter at awsmtek.com
Sat Jan 1 22:02:27 UTC 2022


Ok I see.
The master branch is a bit ahead of my local one.
And I really don't know what to think about these conflicts:
```
# Conflicts:
# bsps/arm/stm32f4/headers.am
# bsps/arm/stm32f4/include/bsp/irq.h
# bsps/arm/stm32f4/start/bsp_specs
# c/src/lib/libbsp/arm/stm32f4/Makefile.am
```
Has `arm/stm32f4` been eliminated from the main source tree?

Best regards.
Peter Borisenko
Awesome Technologies, Ltd.
http://awsmtek.com
hardware at awsmtek.com
+79062165482


On Sun, Jan 2, 2022 at 12:13 AM <groups at chichak.ca> wrote:

> I reported this, Set fixed it, and the report was closed.
>
> Either someone said “multilib, multilib, multilib” and it came back, Peter
> needs to do a pull, or something has reverted.
>
> https://devel.rtems.org/ticket/4504
>
> A
>
> On 2022-January-01, at 13:56, Петр Борисенко <peter at awsmtek.com> wrote:
>
> I didn't print anything explisitly.
> Here is call stack:
> ```
> Thread #1 (Suspended : Signal : SIGINT:Interrupt)
> output_char() at console-config.c:104 0x8007132
> rtems_putc() at rtems_putc.c:31 0x800f038
> _IO_Vprintf() at iovprintf.c:133 0x800b8b4
> vprintk() at vprintk.c:31 0x8009aa0
> printk() at printk.c:40 0x800794e
> bsp_fatal_extension() at bspfatal-default.c:26 0x8006ea2
> _User_extensions_Iterate() at userextiterate.c:181 0x800e686
> _User_extensions_Fatal() at userextimpl.h:446 0x800b856
> _Terminate() at interr.c:38 0x800b856
> rtems_fatal() at fatal.h:158 0x80103a6
> _ARM_Exception_default() at arm-exception-default.c:24 0x80103a6
> <signal handler called>() at 0xfffffff9
> 0x0
> ```
>
> Best regards.
> Peter Borisenko
> Awesome Technologies, Ltd.
> http://awsmtek.com
> hardware at awsmtek.com
> +79062165482
>
>
> On Sat, Jan 1, 2022 at 7:09 PM Joel Sherrill <joel at rtems.org> wrote:
>
>> Assuming it is compiled correctly, printing this early should be via
>> printk().
>>
>> Can you attach gdb and just walk through the BSP initialisation?
>>
>> --joel
>>
>> On Sat, Jan 1, 2022, 2:08 AM <groups at chichak.ca> wrote:
>>
>> > (sorry, I accidentally sent this to the dev list instead of users. too
>> > much cheer)
>> >
>> > It’s bombing in printf. It’s so early that the stack hasn’t been set up
>> > yet, and it’s found an error and it’s trying to poot a message out on
>> the
>> > console, which is also not set up yet.
>> >
>> > Umm, what could be wrong? Lemme think… (I’ve worked wth this bsp in
>> > RTEMS4.11, and a version in RTEMS5)
>> >
>> > I had problems with that BSP blowing up just like this because portions
>> of
>> > it weren’t compiled with the proper instruction set, and when the
>> startup
>> > code called memset (I think), it would call memset in newlib/libc that
>> was
>> > compiled for the wrong architecture, do the wrong thing, end up in
>> printf
>> > and die a horrible death.
>> >
>> > Let’s see if I can find the thread on Discord…
>> >
>> > around August 19/2021
>> >
>> > run:
>> >
>> > rtems-exeinfo -O blah.exe
>> >
>> > and make sure that all of the functions have the same architecture
>> > specified. Mine had a mix of -mcpu=cortex-m4 and -mcpu=arm7tdmi which
>> are
>> > incompatible.
>> >
>> >
>> >
>> > Andrei Chichak
>> > (from The Great White North)
>> >
>> >
>> > > On 2021-December-31, at 18:48, Петр Борисенко <peter at awsmtek.com>
>> wrote:
>> > >
>> > > Hello and Happy new year!
>> > > I am getting an error during startup:
>> > > RTEMS_FATAL_SOURCE_EXCEPTION
>> > > Catching it in _ARM_Exception_default.
>> > > The bsp is `arm/stm32f4`.
>> > > Here is contains of CPU_Exception_frame:
>> > > register_r0 uint32_t 0x80139bc
>> > > register_r1 uint32_t 0
>> > > register_r2 uint32_t 0
>> > > register_r3 uint32_t 76
>> > > register_r4 uint32_t 0
>> > > register_r5 uint32_t 0
>> > > register_r6 uint32_t 0
>> > > register_r7 uint32_t 0
>> > > register_r8 uint32_t 0
>> > > register_r9 uint32_t 0
>> > > register_r10 uint32_t 0
>> > > register_r11 uint32_t 0
>> > > register_r12 uint32_t 0
>> > > register_sp uint32_t 536909088
>> > > register_lr void * 0x80001c3 <bsp_start_hook_0_done+4>
>> > > register_pc void * 0x8013f08 <_svfprintf_r+8152>
>> > > register_xpsr uint32_t 16777216
>> > > vector uint32_t 3
>> > > vfp_context const ARM_VFP_context * 0x0
>> > > reserved_for_stack_alignment uint32_t 3522771716
>> > > &Console_Port_Minor rtems_device_minor_number * 0x20006988
>> > > <Console_Port_Minor>
>> > > *&Console_Port_Minor rtems_device_minor_number 1363452156
>> > >
>> > > What could it be? Any common reasons? Or what additional info should I
>> > > provide?
>> > >
>> > > Also it would be really appreciated if someone will help me
>> export/build
>> > > bsp as a debuggable source tree.
>> > >
>> > > Best regards.
>> > > Peter Borisenko
>> > > Awesome Technologies, Ltd.
>> > > http://awsmtek.com
>> > > hardware at awsmtek.com
>> > > +79062165482
>> > > _______________________________________________
>> > > users mailing list
>> > > users at rtems.org
>> > > http://lists.rtems.org/mailman/listinfo/users
>> >
>> > _______________________________________________
>> > devel mailing list
>> > devel at rtems.org
>> > http://lists.rtems.org/mailman/listinfo/devel
>> > _______________________________________________
>> > users mailing list
>> > users at rtems.org
>> > http://lists.rtems.org/mailman/listinfo/users
>> _______________________________________________
>> users mailing list
>> users at rtems.org
>> http://lists.rtems.org/mailman/listinfo/users
>
>
>


More information about the users mailing list