How can I handle situation , when even empty project stacks at Reset Handler without running code? Code was generated in 1.02 version of CubeIDE for STM32WB55RG . Breakpoints were set on some places in main.c (f.e. Hal_Init() )

[MKraw]

[Bob S]

> stacks at Reset Handler

Huh??? Do you mean "STOPS" at reset handler? Have you stepped through the startup code? If so, what happens? Does a loop never end? Do you end up in a fault handler? Unless you have specifically provided code for fault handlers, getting a fault usually means ending up in an infinite "branch here" instruction just after the call to main.

[Tesla DeLorean]

I'd make sure the _estack pointer is correctly aligned and points to usable memory. I seem to recall a couple of complaints in recent weeks that _estack is set beyond the reach of available RAM (0x20005000 ??), check the .LD (loader script) vs documentation for the part in question.

[MKraw]

loop don't even starts .

in STM32WB55RGVX_RAM.ld and STM32WB55RGVX_FLASH.ld - I got 0x20040000 - is that correct value?

[Tesla DeLorean]

Seems to be within scope based on a glance at the data sheet. Wonder if there is a specific clock enable for it?

This is the thread I remember

https://community.st.com/s/question/0D50X0000AwYRnOSQW/what-would-cause-a-hard-fault-on-assembly-instruction-bl-branch-with-link-in-startupstm32wb55cguxs-

[Tesla DeLorean · Accepted solution]

I'd try putting it at 0x20030000 (Top of 192KB) as that definitely should be available and not protected.

3.3.4 Embedded SRAM

STM32WB55xx devices feature up to 256 KB of embedded SRAM, split in three blocks:

• SRAM1: up to 192 KB mapped at address 0x2000 0000

• SRAM2a: 32 KB located at address 0x2003 0000 (contiguous to SRAM1) also mirrored at 0x1000 0000, with hardware parity check (this SRAM can be retained in Standby mode)

• SRAM2b: 32 KB located at address 0x2003 8000 (contiguous with SRAM2a) and mirrored at 0x1000 8000 with hardware parity check

SRAM2a and SRAM2b can be write-protected, with 1 KB granularity, A section of the SRAM2a and SRAM2b is secured for the RF sub-system and cannot be accessed by the host CPU1.

The SRAMs can be accessed in read/write with 0 wait states for all CPU1 and CPU2 clock speeds.