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: e3100003 tst r0, #3 9a08: 0a000040 beq 9b10 <memset+0x10c> became (from gdb/eclipse) 00009a04: movs r3, r0 00009a06: b.n 0xa02a <strcmp+382> 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 >> <sebastian.hu...@embedded-brains.de> wrote: >> >> On 11/08/2021 18:22, Mr. Andrei Chichak wrote: >>> On 2021-August-11, at 01:06, Sebastian >>> Huber<sebastian.hu...@embedded-brains.de> 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 0x200008A0 > and a length of 28396, so the region being zero’d would be 0x200008A0 - > 0x2000778C. > > According to the map file: > bsp_section_bss_begin == 0x200008A0 > 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 _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
