Re: Having a problem with an out of the box setup for STM32F4
I spent a bunch of time conversing with Chris Johns on Discord about this issue and Chris, with infinite patience, helped me find a possible issue. Using rtems-exeinfo -O we noticed an issue | __atexit.c: -mcpu=arm7tdmi -marm -march=armv4t | __call_atexit.c : -mcpu=arm7tdmi -marm -march=armv4t | __gettod.c: -mthumb -mcpu=cortex-m4 -march=armv7e-m | __usrenv.c: -mthumb -mcpu=cortex-m4 -march=armv7e-m | _free_r.c : -mthumb -mcpu=cortex-m4 -march=armv7e-m | _isatty.c : -mcpu=arm7tdmi -marm -march=armv4t Some of the routines are compiled for an arm7tdmi, and they are the ones in libgcc. Other routines are compiled for cortex-m4, which is appropriate for the STM32F4 family. I tried to figure out where in the building of the compilers/libraries/RTEMS6 this was happening, and Chris, Gedare, and Joel were chanting MULTILIB MULTILIB MULTILIB. I worked hard to understand the local vernacular “what is this MULTILIB thing they speak of?”, figured out that a set of functions got compiled 15 different ways for 15 ARM sub-architectures and stored in a single library (I think), but it started to make sense. If my code is linked with the wrong ARM variant arm of multilib, then my thumb processor could branch into a function that uses ARM instructions instead of thumb, or some thumb dialect that it doesn’t understand, that would be bad. Doing an objdump of a test program came up with a different set of instructions than what I was seeing in gdb/eclipse. From objdump, the first two instructions of memset are: 9a04: e313tst r0, #3 9a08: 0a40beq 9b10 became (from gdb/eclipse) 9a04: movs r3, r0 9a06: b.n 0xa02a The hex values at location 0x9a04, in the second case, were the same as shown in the first case. This is what I’ve been seeing. Memset quickly branches to the middle of strcmp, then culminates in printk. And memset is one of the routines that is compiled with -mcpu=arm7tdmi. I’m not sure how to control what arm of the multilib gcc should use. Can you help? Thanks, Andrei > On 2021-August-12, at 11:37, gro...@chichak.ca wrote: > > > >> On 2021-August-12, at 03:36, Sebastian Huber >> wrote: >> >> On 11/08/2021 18:22, Mr. Andrei Chichak wrote: >>> On 2021-August-11, at 01:06, Sebastian >>> Huber wrote: On 10/08/2021 23:48, Mr. Andrei Chichak wrote: > From what I can figure out, there seems to be a problem with the > out-of-the-box build of newly that the STM32F4 uses. > memset() goes for a few ARM instructions and then seems to intentionally > branch into, what the map file indicates is, the middle of fflush(). When does this happen, during the system start or later? >>> This is happening at startup. >>> bsp_start_hook_1 calls bsp_start_copy_sections and the required sections >>> are copied properly. I can trace this code and watch the regions get copied >>> when needed. >>> bsp_start_hook_1 then calls bsp_start_clear_bss (in start.h) which calls >>> memset with a valid pointer and size, but within a few instructions my >>> processor (STM32F407G-DISC1 board) has, according to the stack, gone >>> through rtems_fatal, _Terminate, all the way down to items_putc, and the >>> bus doesn’t get cleared. >> >> Is the memory of the memset() initialized? > > No, it is random before the call and doesn’t get altered. > >> Is it the right area? > > I believe it is. > > The call to memset is being called with a destination address of 0x28A0 > and a length of 28396, so the region being zero’d would be 0x28A0 - > 0x2000778C. > > According to the map file: > bsp_section_bss_begin == 0x28A0 > bsp_section_bss_end == 0x2000778C > bsp_section_bss_size = 0x6EEC > > From what I can see, memset is being called with the proper start address and > length > >> Does it overlap the stack? > > From reset, the initial stack pointer is 0x200097A0 (as seen at location 0x0 > and observed in the sp register in the debugger), so the region being cleared > is well below the stack (the stack pointer at the point of the memset call is > 0x200097A0) > > From the map file: > bsp_section_rtemsstack_begin == 0x200077A0 > bsp_section_rtemsstack_end == 0x200097A0 > bsp_section_rtemsstack_size == 0x2000 > > So that checks out too. > > Also if, from the debugger, I modify RAM around the bss region, it is > writable, readable, and survives a reset. > > And I was originally working on a BSP for the STM32F767 (very similar to the > 407 and my BSP was based on your 407 BSP), have been running RTEMS5 on that > processor on a commercial product for a few years now, and I encountered this > exact same issue on my ‘767 boards when I switched over to RTEMS6. (767 has > more RAM starting at the same location) > > > Andrei > > >
Re: Having a problem with an out of the box setup for STM32F4
> On 2021-August-12, at 03:36, Sebastian Huber > wrote: > > On 11/08/2021 18:22, Mr. Andrei Chichak wrote: >> On 2021-August-11, at 01:06, Sebastian >> Huber wrote: >>> On 10/08/2021 23:48, Mr. Andrei Chichak wrote: From what I can figure out, there seems to be a problem with the out-of-the-box build of newly that the STM32F4 uses. memset() goes for a few ARM instructions and then seems to intentionally branch into, what the map file indicates is, the middle of fflush(). >>> When does this happen, during the system start or later? >> This is happening at startup. >> bsp_start_hook_1 calls bsp_start_copy_sections and the required sections are >> copied properly. I can trace this code and watch the regions get copied when >> needed. >> bsp_start_hook_1 then calls bsp_start_clear_bss (in start.h) which calls >> memset with a valid pointer and size, but within a few instructions my >> processor (STM32F407G-DISC1 board) has, according to the stack, gone through >> rtems_fatal, _Terminate, all the way down to items_putc, and the bus doesn’t >> get cleared. > > Is the memory of the memset() initialized? No, it is random before the call and doesn’t get altered. > Is it the right area? I believe it is. The call to memset is being called with a destination address of 0x28A0 and a length of 28396, so the region being zero’d would be 0x28A0 - 0x2000778C. According to the map file: bsp_section_bss_begin == 0x28A0 bsp_section_bss_end == 0x2000778C bsp_section_bss_size = 0x6EEC From what I can see, memset is being called with the proper start address and length > Does it overlap the stack? From reset, the initial stack pointer is 0x200097A0 (as seen at location 0x0 and observed in the sp register in the debugger), so the region being cleared is well below the stack (the stack pointer at the point of the memset call is 0x200097A0) From the map file: bsp_section_rtemsstack_begin == 0x200077A0 bsp_section_rtemsstack_end == 0x200097A0 bsp_section_rtemsstack_size == 0x2000 So that checks out too. Also if, from the debugger, I modify RAM around the bss region, it is writable, readable, and survives a reset. And I was originally working on a BSP for the STM32F767 (very similar to the 407 and my BSP was based on your 407 BSP), have been running RTEMS5 on that processor on a commercial product for a few years now, and I encountered this exact same issue on my ‘767 boards when I switched over to RTEMS6. (767 has more RAM starting at the same location) Andrei ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Having a problem with an out of the box setup for STM32F4
On 11/08/2021 18:22, Mr. Andrei Chichak wrote: On 2021-August-11, at 01:06, Sebastian Huber wrote: On 10/08/2021 23:48, Mr. Andrei Chichak wrote: From what I can figure out, there seems to be a problem with the out-of-the-box build of newly that the STM32F4 uses. memset() goes for a few ARM instructions and then seems to intentionally branch into, what the map file indicates is, the middle of fflush(). When does this happen, during the system start or later? This is happening at startup. bsp_start_hook_1 calls bsp_start_copy_sections and the required sections are copied properly. I can trace this code and watch the regions get copied when needed. bsp_start_hook_1 then calls bsp_start_clear_bss (in start.h) which calls memset with a valid pointer and size, but within a few instructions my processor (STM32F407G-DISC1 board) has, according to the stack, gone through rtems_fatal, _Terminate, all the way down to items_putc, and the bus doesn’t get cleared. Is the memory of the memset() initialized? Is it the right area? Does it overlap the stack? -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Having a problem with an out of the box setup for STM32F4
On 2021-August-11, at 01:06, Sebastian Huber wrote: > > On 10/08/2021 23:48, Mr. Andrei Chichak wrote: >> From what I can figure out, there seems to be a problem with the >> out-of-the-box build of newly that the STM32F4 uses. >> memset() goes for a few ARM instructions and then seems to intentionally >> branch into, what the map file indicates is, the middle of fflush(). > > When does this happen, during the system start or later? This is happening at startup. bsp_start_hook_1 calls bsp_start_copy_sections and the required sections are copied properly. I can trace this code and watch the regions get copied when needed. bsp_start_hook_1 then calls bsp_start_clear_bss (in start.h) which calls memset with a valid pointer and size, but within a few instructions my processor (STM32F407G-DISC1 board) has, according to the stack, gone through rtems_fatal, _Terminate, all the way down to items_putc, and the bus doesn’t get cleared. Andrei ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Having a problem with an out of the box setup for STM32F4
On 10/08/2021 23:48, Mr. Andrei Chichak wrote: From what I can figure out, there seems to be a problem with the out-of-the-box build of newly that the STM32F4 uses. memset() goes for a few ARM instructions and then seems to intentionally branch into, what the map file indicates is, the middle of fflush(). When does this happen, during the system start or later? -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Having a problem with an out of the box setup for STM32F4
Sorry, I put in newlib and this stupid mail program put in newly. > On 2021-August-10, at 15:48, Mr. Andrei Chichak wrote: > > From what I can figure out, there seems to be a problem with the > out-of-the-box build of newly that the STM32F4 uses. > > memset() goes for a few ARM instructions and then seems to intentionally > branch into, what the map file indicates is, the middle of fflush(). > > newly would have been built with this command (from the quick start section > of the RTEMS user manual) > > ../source-builder/sb-set-builder --prefix=$HOME/quick-start/rtems/6 > 6/rtems-arm > > Help. I’m drowning. > > Andrei ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Having a problem with an out of the box setup for STM32F4
From what I can figure out, there seems to be a problem with the out-of-the-box build of newly that the STM32F4 uses. memset() goes for a few ARM instructions and then seems to intentionally branch into, what the map file indicates is, the middle of fflush(). newly would have been built with this command (from the quick start section of the RTEMS user manual) ../source-builder/sb-set-builder --prefix=$HOME/quick-start/rtems/6 6/rtems-arm Help. I’m drowning. Andrei___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
