RTEMS_FATAL_SOURCE_EXCEPTION during startup

Sat Jan 1 22:25:15 UTC 2022

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
>>
>>
>>