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 hardw...@awsmtek.com +79062165482 On Sun, Jan 2, 2022 at 12:13 AM <gro...@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, Петр Борисенко <pe...@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 > hardw...@awsmtek.com > +79062165482 > > > On Sat, Jan 1, 2022 at 7:09 PM Joel Sherrill <j...@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 <gro...@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, Петр Борисенко <pe...@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 >> > > hardw...@awsmtek.com >> > > +79062165482 >> > > _______________________________________________ >> > > users mailing list >> > > users@rtems.org >> > > http://lists.rtems.org/mailman/listinfo/users >> > >> > _______________________________________________ >> > devel mailing list >> > de...@rtems.org >> > http://lists.rtems.org/mailman/listinfo/devel >> > _______________________________________________ >> > users mailing list >> > users@rtems.org >> > http://lists.rtems.org/mailman/listinfo/users >> _______________________________________________ >> users mailing list >> users@rtems.org >> http://lists.rtems.org/mailman/listinfo/users > > > _______________________________________________ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
