> 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
