Having a problem with an out of the box setup for STM32F4

[groups at chichak.ca]

> On 2021-August-12, at 03:36, Sebastian Huber <sebastian.huber at embedded-brains.de> wrote:
> 
> On 11/08/2021 18:22, Mr. Andrei Chichak wrote:
>> On 2021-August-11, at 01:06, Sebastian Huber<sebastian.huber at 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