RTEMS_FATAL_SOURCE_EXCEPTION during startup

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


 Ok, I got it. We moved from autotools to waf completely.
Hence I wrote my bsp extensions upon the new structure (but completely
forgot about it since I didn't touch the project for a half of a year)
Ok, thanks guys! I will try to figure out my build configuration and will
ask if something else is going on wrong!

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


On Sun, Jan 2, 2022 at 1:25 AM Joel Sherrill <joel at rtems.org> wrote:

>
>
> On Sat, Jan 1, 2022, 4:02 PM Петр Борисенко <peter at awsmtek.com> wrote:
>
>> 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:
>>
>
> If this is applying a patch for an older version of RTEMS to the master,
> the build system has changed
>
> ```
>> # Conflicts:
>> # bsps/arm/stm32f4/headers.am
>>
>
> Part of the old build system
>
>>
>> # bsps/arm/stm32f4/include/bsp/irq.h
>>
>
> Will have to be resolved.
>
> # bsps/arm/stm32f4/start/bsp_specs
>>
>
> Gone now.
>
> # c/src/lib/libbsp/arm/stm32f4/Makefile.am
>>
>
> Old build system.
>
>> ```
>> Has `arm/stm32f4` been eliminated from the main source tree?
>>
>
> It is still there. Under bsps/arm.
>
> The changes to those.filea may have to be translated to the current master.
>
> Andrei will be more familiar. I answering from my phone.
>
>
>> 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