Why does STM32CubeIDE version 1.9.0. create non resetable code?

[Steniweb]

I am working with STM32V Discovery Boards that do not allow debugging functionality of STM32CubeIDE. I create Intel HEX code and download it into the board via ST-Link Utility. That worked quite well with version STM32CubeIDE 1.6.0**

Recently I switched to 1.9.0. I skipped the versions 1.7.x and 1.8.x. Now, what happens is that the code is downloaded and starts. But the hardware reset does not work anymore. Whenever I press the black RST button the board remains dead.

Can anybody tell me the cause for this behaviour and give an idea how to solve this issue?!

[Tesla DeLorean]

Does sound odd.

Check it's not re-configuring the GPIO or SWD/JTAG pins, or Cube's defaulted to disabling debug connectivity.

I'd wager that the reset does work, just dies some place else, ie ErrorHandler() or HardFault_Handler()

Scope the NRST pin

[Paul1]

1) Try setting a breakpoint at main(), or even in the initialization code. Then step forward from there to see where it dies.

2) Ensure the project is built for the correct MCU with all the part number suffix, possibly a slightly different memory map or features. You can program code into STM's of same family to allow using different ICs in production (nice during shortages like now), but that can cause issues if the code expects some MCU feature that isn't there or gets initialized differently.

Paul

[Markus GIRDLAND]

I believe the board you are using has ST-Link v1 which isn't officially supported by STM32CubeIDE, so I couldn't guarantee it working either way.

However, a few points where it could potentially fail between 1.6.0 and 1.9.0 are:

• Compiler, new toolchain in the new version could mess things up. You could try to use the old toolchain.
• Code, how the code is written and possibly generated by MX could change which could affect the behavior
• Flash, perhaps it's not actually flashing correctly.

Once again, this is just some ideas that you could verify on your end.