2025-09-03 3:35 AM - last edited on 2025-09-03 3:41 AM by Andrew Neil
Hello there : )
This may be resolved but I cannot find the answer in either Segger's or ST's forum.
I have set up a fresh target (NUCLEO-G491RE) via ST-LINK with expected result.
When I move SRAM1 -> address 0 it is changed in the memory view.
Now, with a J-LINK it never changes, (not after refreshing the memory view either).
I have changed the OB to initially put the main FLASH at address 0 (BOOT0 pin will not be valid later).
As ST-LINK connects this is confirmed as SYSCFG.MEMRMP is 0x1, and changes to 0x3 correctly.
The J-LINK does however starts with 0x0 and changes to 0x3 as expected.
In both cases the SYSCFG.CFGR1 changes from 0x0 to 0x7C... before so the RCC does it's work.
Any ideas?
BTW, the J-LINK Console log does not mention about any of this, no script are involved.
2025-09-12 3:32 AM
Hello @HenrikGlader
This behavior is most likely due to how J-LINK handles memory remapping and boot configuration, rather than a problem with STM32CubeIDE itself. You should try changing the reset mode in the STM32CubeIDE debug configuration to "Connect under reset" or "Hardware reset" to ensure the debugger respects the Option Bytes. Additionally, use STM32CubeProgrammer to verify your Option Bytes settings. If the issue persists, document your findings including register values and memory view behavior and report them to SEGGER support for further assistance.
THX
Ghofrane
To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.
2025-09-15 1:09 AM
Well, the effect remains the same in either "Connect under reset" option.
I see a <... J-LINK.launch> file in the project root where i'd guess some magical things are being set.
However, I cannot make sense of this xml-file.
Makes me wonder if the file is a STM or Segger file.
Thank you for your time = )