[BUG] STM32F411CE: BSS segment memory corruption during z_bss_zero() causes infinite loop in memset

[wentywenty]

Describe the bug

Environment

• Board: STM32F411CE
• Zephyr Version: 1.3.0
• SDK Version: zephyr-sdk-0.17.0
• Host OS: Windows 11
• Toolchain: arm-zephyr-eabi-gcc 12.2.0

Bug Description

During Zephyr kernel initialization on STM32F411CE, the system gets stuck in an infinite loop within memset() called from z_bss_zero(). The issue appears to be a memory address calculation error where the BSS segment boundaries are incorrectly computed.

Reproduction Steps

1. Create minimal Zephyr application for STM32F411CE
2. Build with west build -p auto
3. Flash to STM32F411CE BlackPill board
4. Debug with GDB: the system halts at z_bss_zero() → z_early_memset() → memset()

Expected Behavior

• BSS segment should be properly cleared during initialization
• System should proceed to main() function
• Application should run normally

Actual Behavior

• memset() enters infinite loop at addresses 0x080019e6 - 0x080019f0
• BSS memory boundaries are incorrectly calculated
• System never reaches main() function

Debug Analysis

GDB Investigation Results:

BSS Segment Information:

(gdb) info symbol __bss_start
z_malloc_heap in section bss

(gdb) info symbol __bss_end
No symbol matches __bss_end.    # ← MISSING SYMBOL!

(gdb) print __bss_end - __bss_start
$1 = 244

(gdb) info address z_malloc_heap
Symbol "z_malloc_heap" is static storage at address 0x2000022c.

(gdb) print sizeof(z_malloc_heap)
$2 = 12

memset() Parameters During Hang:

(gdb) info registers r0 r1 r2 r3
r0  0x20000068    # start address (WRONG!)
r1  0x0           # clear value (correct)
r2  0x20000394    # end address (WRONG!)
r3  0x2000006d    # current pointer

Critical Issue:

• Expected BSS: 0x2000022c (12 bytes)
• Actual memset range: 0x20000068 to 0x20000394 (812 bytes)
• Missing symbol: __bss_end is undefined

Assembly Analysis:

# Infinite loop in memset():
0x080019e6 <memset+4>:  cmp   r3, r2      
0x080019e8 <memset+6>:  bne.n 0x80019ec   
0x080019ea <memset+8>:  bx    lr          
0x080019ec <memset+10>: strb.w r1, [r3], #1  
0x080019f0:             b     0x080019e6    # ← LOOPS HERE

Call Stack:

z_arm_reset() → z_prep_c() → z_bss_zero() → z_early_memset() → memset()

Memory Configuration

CONFIG_SRAM_SIZE=128
CONFIG_SRAM_BASE_ADDRESS=0x20000000
CONFIG_MAIN_STACK_SIZE=129000

Workaround

The issue can be bypassed in GDB by:

(gdb) b main
(gdb) jump main  # Skip problematic BSS clearing

Root Cause Analysis

1. Missing __bss_end symbol in linker script
2. Incorrect BSS boundary calculation in z_bss_zero()
3. Memory corruption - memset overwrites stack/heap areas
4. STM32F411CE-specific memory layout issue

Impact

• Critical: System cannot boot normally
• Affects: All STM32F411CE applications using Zephyr
• Workaround required: Manual GDB intervention needed

Suggested Fix

1. Verify linker script defines __bss_end symbol correctly
2. Add boundary validation in z_bss_zero()
3. Add memory protection checks for STM32F411CE
4. Review BSS segment calculation logic

Additional Debug Logs

# Zephyr build output shows:
Loading section rom_start, size 0x198 lma 0x8000000
Loading section text, size 0x1920 lma 0x8000198
# ... (no BSS section information)

# Vector table shows incorrect stack pointer:
Contents of section rom_start:
 8000000 68f90120 4d080008 7d050008 39080008  h.. M...}...9...
# Stack pointer: 0x2001f968 (should be 0x20020000)

Regression

• This is a regression.

Steps to reproduce

(zephyrproject) PS D:\zephyrproject\zephyrproject\zephyr\samples\sbrviz2_zephyr> arm-none-eabi-gdb build\zephyr\zephyr.elf
GNU gdb (Arm GNU Toolchain 14.2.Rel1 (Build arm-14.52)) 15.2.90.20241130-git
Copyright (C) 2024 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "--host=i686-w64-mingw32 --target=arm-none-eabi".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
https://bugs.linaro.org/.
Find the GDB manual and other documentation resources online at:
http://www.gnu.org/software/gdb/documentation/.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from build\zephyr\zephyr.elf...
(gdb) target extended-remote :3333
`D:\zephyrproject\zephyrproject\zephyr\samples\sbrviz2_zephyr\build\zephyr\zephyr.elf' has changed; re-reading symbols.
could not connect (error 138): ?????????????????????
(gdb) target extended-remote :3333
Remote debugging using :3333
0x1fff1c18 in ?? ()
(gdb) load
Loading section rom_start, size 0x198 lma 0x8000000
Loading section text, size 0x34a4 lma 0x8000198
Loading section .ARM.exidx, size 0x8 lma 0x800363c
Loading section initlevel, size 0x80 lma 0x8003644
Loading section device_area, size 0xf0 lma 0x80036c4
Loading section sw_isr_table, size 0x2b0 lma 0x80037b4
Loading section gpio_driver_api_area, size 0x24 lma 0x8003a64
Loading section reset_driver_api_area, size 0x10 lma 0x8003a88
Loading section clock_control_driver_api_area, size 0x1c lma 0x8003a98
Loading section uart_driver_api_area, size 0x4c lma 0x8003ab4
Loading section rodata, size 0x2bc lma 0x8003b00
Loading section datas, size 0x4c lma 0x8003dbc
Loading section device_states, size 0x18 lma 0x8003e08
Loading section .last_section, size 0x4 lma 0x8003e20
Start address 0x080008ec, load size 15908
Transfer rate: 22 KB/sec, 795 bytes/write.
(gdb) monitor reset halt
Resetting target with halt
Successfully halted device on reset
(gdb) stepi
125 msr BASEPRI, r0
(gdb) stepi
154 ldr r0, =z_interrupt_stacks
(gdb) stepi
155 ldr r1, =CONFIG_ISR_STACK_SIZE + MPU_GUARD_ALIGN_AND_SIZE
(gdb) stepi
156 adds r0, r0, r1
(gdb) stepi
157 msr PSP, r0
(gdb) stepi
158 mrs r0, CONTROL
(gdb) stepi
159 movs r1, #2
(gdb) stepi
160 orrs r0, r1 /* CONTROL_SPSEL_Msk */
(gdb) stepi
161 msr CONTROL, r0
(gdb) stepi
z_arm_reset ()
at D:/zephyrproject/zephyrproject/zephyr/arch/arm/core/cortex_m\reset.S:167
167 isb
(gdb) stepi
174 bl z_prep_c
(gdb) stepi
relocate_vector_table ()
at D:/zephyrproject/zephyrproject/zephyr/arch/arm/core/cortex_m/prep_c.c:56
56 SCB->VTOR = VECTOR_ADDRESS & VTOR_MASK;
(gdb) stepi
0x08000a16 in z_prep_c ()
at D:/zephyrproject/zephyrproject/zephyr/arch/arm/core/cortex_m/prep_c.c:191
191 {
(gdb) stepi
0x08000a18 in relocate_vector_table ()
at D:/zephyrproject/zephyrproject/zephyr/arch/arm/core/cortex_m/prep_c.c:56
56 SCB->VTOR = VECTOR_ADDRESS & VTOR_MASK;
(gdb) stepi
0x08000a1a 56 SCB->VTOR = VECTOR_ADDRESS & VTOR_MASK;
(gdb) stepi
0x08000a1e 56 SCB->VTOR = VECTOR_ADDRESS & VTOR_MASK;
(gdb) stepi
__DSB ()
at D:/zephyrproject/zephyrproject/modules/hal/cmsis/CMSIS/Core/Include/cmsis_gcc.h:271
271 __ASM volatile ("dsb 0xF":::"memory");
(gdb) stepi
__ISB ()
at D:/zephyrproject/zephyrproject/modules/hal/cmsis/CMSIS/Core/Include/cmsis_gcc.h:260
260 __ASM volatile ("isb 0xF":::"memory");
(gdb) stepi
z_arm_floating_point_init ()
at D:/zephyrproject/zephyrproject/zephyr/arch/arm/core/cortex_m/prep_c.c:89
89 SCB->CPACR &= ((CPACR_CP10_Msk | CPACR_CP11_Msk));
(gdb) stepi
0x08000a2c 89 SCB->CPACR &= ((CPACR_CP10_Msk | CPACR_CP11_Msk));
(gdb) stepi
0x08000a30 89 SCB->CPACR &= (~(CPACR_CP10_Msk | CPACR_CP11_Msk));
(gdb) stepi
__get_CONTROL ()
at D:/zephyrproject/zephyrproject/modules/hal/cmsis/CMSIS/Core/Include/cmsis_gcc.h:975
975 __ASM volatile ("MRS %0, control" : "=r" (result) );
(gdb) stepi
z_arm_floating_point_init ()
at D:/zephyrproject/zephyrproject/modules/hal/cmsis/CMSIS/Core/Include/cmsis_gcc.h:1003
1003 __ASM volatile ("MSR control, %0" : : "r" (control) : "memory");
(gdb) stepi
0x08000a3c in __set_CONTROL (control=2)
at D:/zephyrproject/zephyrproject/modules/hal/cmsis/CMSIS/Core/Include/cmsis_gcc.h:1003
1003 __ASM volatile ("MSR control, %0" : : "r" (control) : "memory");
(gdb) stepi
__ISB ()
at D:/zephyrproject/zephyrproject/modules/hal/cmsis/CMSIS/Core/Include/cmsis_gcc.h:260
260 __ASM volatile ("isb 0xF":::"memory");
(gdb) stepi
z_prep_c ()
at D:/zephyrproject/zephyrproject/zephyr/arch/arm/core/cortex_m/prep_c.c:200
200 z_bss_zero();
(gdb) stepi
z_bss_zero ()
at D:/zephyrproject/zephyrproject/zephyr/kernel/init.c:225
225 z_early_memset(__bss_start, 0, __bss_end - __bss_start);
(gdb) stepi
0x08001c82 225 z_early_memset(__bss_start, 0, __bss_end - __bss_start);
(gdb) stepi
0x08001c84 225 z_early_memset(__bss_start, 0, __bss_end - __bss_start);
(gdb) stepi
0x08001c86 225 z_early_memset(__bss_start, 0, __bss_end - __bss_start);
(gdb) stepi
0x08001c88 225 z_early_memset(__bss_start, 0, __bss_end - __bss_start);
(gdb) stepi
0x08001c8a 225 z_early_memset(__bss_start, 0, __bss_end - __bss_start);
(gdb) stepi
z_early_memset (dst=0x20000068 <announced_cycles>, c=0,
n=812)
at D:/zephyrproject/zephyrproject/zephyr/kernel/init.c:197
197 (void) memset(dst, c, n);
(gdb) stepi
0x0800355a in memset ()
(gdb) stepi
0x0800355c in memset ()
(gdb) stepi
0x0800355e in memset ()
(gdb) stepi
0x08003560 in memset ()
(gdb) stepi
0x08003564 in memset ()
(gdb) stepi
0x08003568 in memset ()
(gdb) stepi
0x0800355e in memset ()
(gdb) stepi
0x08003560 in memset ()
(gdb) stepi
0x08003564 in memset ()
(gdb) stepi
0x08003568 in memset ()
(gdb) stepi
0x0800355e in memset ()
(gdb) stepi
0x08003560 in memset ()
(gdb) stepi
0x08003564 in memset ()
(gdb) disassemble $pc-8,$pc+8
Dump of assembler code from 0x800355c to 0x800356c:
0x0800355c <memset+2>: mov r3, r0
0x0800355e <memset+4>: cmp r3, r2
0x08003560 <memset+6>: bne.n 0x8003564 <memset+10>
0x08003562 <memset+8>: bx lr
=> 0x08003564 <memset+10>: strb.w r1, [r3], #1
0x08003568 <memset+14>: b.n 0x800355e <memset+4>
0x0800356a <strnlen+0>: push {r4, lr}
End of assembler dump.
(gdb)

Relevant log output

Impact

Annoyance – Minor irritation; no significant impact on usability or functionality.

Environment

No response

Additional Context

No response

[github-actions]

Hi @wentywenty! We appreciate you submitting your first issue for our open-source project. 🌟

Even though I'm a bot, I can assure you that the whole community is genuinely grateful for your time and effort. 🤖💙

[wentywenty]

30 for (;;) {
(gdb) stepi
30 for (;;) {
(gdb) stepi
30 for (;;) {
(gdb) stepi
30 for (;;) {
(gdb) info registers r0 r1 r2 r3
r0 0x13 19
r1 0x20000a00 536873472
r2 0x0 0
r3 0x10 16
(gdb) info registers r0 r1 r2 r3Quit
(gdb) print reason
$1 = 19
(gdb) bt
#0 arch_system_halt (reason=19)
at D:/zephyrproject/zephyrproject/zephyr/kernel/fatal.c:30
#1 0x08002200 in k_sys_fatal_error_handler (reason=,
esf=) at D:/zephyrproject/zephyrproject/zephyr/kernel/fatal.c:44
#2 0x08002214 in z_fatal_error (reason=, esf=)
at D:/zephyrproject/zephyrproject/zephyr/kernel/fatal.c:119
#3 0x08001990 in z_arm_fatal_error (reason=,
esf=esf@entry=0x20000a00 <z_interrupt_stacks+2048>)
at D:/zephyrproject/zephyrproject/zephyr/arch/arm/core/fatal.c:86
#4 0x0800074e in z_arm_fault (msp=, psp=,
exc_return=, callee_regs=)
at D:/zephyrproject/zephyrproject/zephyr/arch/arm/core/cortex_m/fault.c:1080
#5 0x08000818 in z_arm_usage_fault ()
at D:/zephyrproject/zephyrproject/zephyr/arch/arm/core/cortex_m\fault_s.S:102
#6
#7 0x00000000 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb) info registers
r0 0x13 19
r1 0x20000a00 536873472
r2 0x0 0
r3 0x10 16
r4 0x0 0
r5 0x0 0
r6 0x20000a20 536873504
r7 0x20000a08 536873480
r8 0x0 0
r9 0x0 0
r10 0x0 0
r11 0x0 0
r12 0x0 0
sp 0x200009e8 0x200009e8 <z_interrupt_stacks+2024>
lr 0x8002201 0x8002201 <z_fatal_error>
pc 0x80021f8 0x80021f8 <arch_system_halt+14>
xpsr 0x21000004 553648132
fpscr 0x0 0
msp 0x200009e8 0x200009e8 <z_interrupt_stacks+2024>
psp 0x200009e8 0x200009e8 <z_interrupt_stacks+2024>
primask 0x0 0
control 0x0 0
basepri 0x10 16
faultmask 0x0 0
(gdb) up
#1 0x08002200 in k_sys_fatal_error_handler (reason=,
esf=) at D:/zephyrproject/zephyrproject/zephyr/kernel/fatal.c:44
44 arch_system_halt(reason);
(gdb) list
39 {
40 ARG_UNUSED(esf);
41
42 LOG_PANIC();
43 LOG_ERR("Halting system");
44 arch_system_halt(reason);
45 CODE_UNREACHABLE;
46 }
47 /* LCOV_EXCL_STOP */
48
(gdb)

[dkalowsk]

@erwango if you feel this should be higher priority please adjust as needed.

[JarmouniA]

Zephyr Version: 1.3.0

@wentywenty !??

[wentywenty]

---

Problem Description: Zephyr RTOS on STM32F411CEU6 - memset() Infinite Loop During Early Boot

I am debugging a Zephyr RTOS application on an STM32F411CEU6 microcontroller. The core issue is that the system appears to get stuck in an infinite loop within the memset() function during the very early boot process, specifically when initializing the BSS (Block Started by Symbol) section via z_bss_zero() which calls z_early_memset().

Here's a summary of the observations and debugging steps so far:

• Observed Behavior:

  • When the program is halted in GDB and then allowed to run (e.g., using c or repeated stepi), it consistently enters the memset() function.
  • Within memset(), the Program Counter (PC) repeatedly cycles between the core loop instructions (0x080043c2 to 0x080043cc).
  • Crucially, detailed stepi analysis shows that the strb.w r1, [r3], #1 instruction (which writes a byte to memory and increments the pointer r3) successfully executes, and the r3 register increments correctly after each write.
  • Memory inspection (x/1xb <address>) confirms that bytes are indeed being zeroed out in the BSS region (e.g., 0x200000a8 successfully changed from 0x41 to 0x00).
  • The memset() function does not complete; the program never returns from it to z_early_memset().

• Initial Suspicions and Eliminations:

  • Memory Access Error (Segmentation Fault/Bus Error): Initially suspected due to being stuck in memset(). However, stepi shows the strb.w instruction completes and r3 increments, suggesting the immediate write operation itself isn't causing a direct, capturable fault at that exact instruction.
  • Incorrect memset() parameters/logic: info args and print commands confirm dst, c, and n are valid (dst=0x20000068, c=0, n=816). disassemble memset confirms standard, correct assembly.
  • Invalid Memory Region: The BSS section (0x20000068 to 0x20000398) is within the valid SRAM range of STM32F411CEU6 (0x20000000 to 0x2001FFFF).
  • Watchdog Timer: This was a strong suspect. Kconfig options CONFIG_WATCHDOG, CONFIG_IWDG, CONFIG_WWDG were checked and explicitly set to n in prj.conf. Disabling them did not resolve the issue.

• Persistent Symptoms & Complications:

  • Despite the memset() loop apparently working, the program consistently "resets" or "hangs" when left to run, requiring a monitor reset halt to regain GDB control. This behavior is consistent with a system reset.
  • Attempts to read MPU registers (0xE000ED9x) in GDB sometimes result in Cannot access memory at address..., indicating the MCU may be in a state where these System Control Space registers are unreachable.
  • A Kconfig warning was encountered during compilation: attempt to assign the value 'n' to the undefined symbol MPU_ARM_V7M. This was resolved by removing the offending line from prj.conf, suggesting CONFIG_MPU_ARM_V7M might be implicitly controlled or not directly configurable in this Zephyr version/board setup.

• Current Hypothesis:
  Given that memset() successfully writes bytes and r3 increments, the most likely cause is a hardware-level reset or unhandled fault occurring during the execution of the memset loop, which is not immediately visible as a GDB-intercepted exception (like a HardFault). This could be due to:

  1. MPU Fault with a malfunctioning/unreachable Fault Handler: An MPU violation does occur, but the Memory Management Fault handler (or a subsequent higher-priority fault handler) itself is not properly invoked or is also crashing/looping, leading to a system reset before GDB can catch it.
  2. Bus Fault with an unhandled handler: Similar to MPU, but related to the bus access itself.
  3. Other implicit reset source: A reset source (e.g., specific SoC feature, or even a very brief power glitch not handled by BOR) that's not the conventional watchdog but still causes a full chip reset.

---

[wentywenty]

This version solves that problem