I'm using MDK-Lite Version 5.23 with a STMicroelectronics STM32F072B-Disco "Discovery" board and I am trying to use the Flash Example provided by the Discovery samples.

I've used this board and toolchain for other examples and I have coded some SPI and GPIO work. The IDE works like a champ. However, for this particular project I can build the code and run it by downloading and using the reset button. I cannot use the debugger on the project as soon as I use the HAL_FLASHEx_Erase() routine. Once I execute that routine the IDE pops up a dialog "Cannot access target. Shutting down debug session."

For what it's worth, I know it's not a programming error because if I download the code and then execute the code by pressing the reset button it will work. I've used this same debugger with a TI board and it was able to program flash and execute flash routines as well. I'm pretty sure I'm not erasing the portion of flash where the code is stored, so it's not that.

If I step over this line in main.c

if (HAL_FLASHEx_Erase(&EraseInitStruct, &PageError) != HAL_OK)

then it drops the debug session. If I instead step into the same line and then step over each of the calls in the flash erase routine, then it will work and eventually step out of the routine and I can debug the rest of the code.

  • Not sure, but maybe the USB side of the CMSIS-DAP has been power-cycled. That board has fairly complex power distribution for the external debug components. Cannot access target probably means the connection (by serial-wire) to the DAP has been broken. Mar 29, 2017 at 22:24
  • Are we talking about the On-board ST-LINK/V2 as debugger? Mar 30, 2017 at 7:18
  • If you're able to share a code image, someone else might be able to verify (and rule out hardware issues). Only have an M7 board myself... Mar 30, 2017 at 12:27
  • Bence Kaulics, its the debugger built in to the stm32f072B-disco board. Its the ST-Link Debugger and not a Keil ULINK2 debugger which is ST-LINK/V2. I have one of those Keil usb connected debugger but it connects to the board with a ribbon cable. I'm using the mini usb ST-Link connector on the board and not a ribbon cable connector. The board derives power from the mini-usb connector and not a separate power supply.
    – netskink
    Mar 30, 2017 at 13:04
  • 1
    Regarding the code sample. The sample is provided by discovery repot from STMicro. The path of the project in the ST repot is Projects/STM32F072B-Discovery/Examples/FLASH/FLASH_EraseProgram. I'm using the MDK-ARM project in that directory. It fails on line 108 where it does HAL_FLASHEx_Erase()
    – netskink
    Mar 30, 2017 at 13:08

1 Answer 1


My guess is that this is a power-supply related at some level. Either the external supply, or on-board switching of power rails.

To clarify the scenario, debug works fine after a hardware reset, but when your target erases a block of flash, the debug connection is dropped?

Debug doesn't care about code running correctly - you can be in lockup state, and halting debug should still work. The only thing at the CPU side which locks out debug is a deadlocked AHB access. This means that the problem is either with the SWD interface between the STM32F7, and the on-board USB-SWD interface chip (also an STM32, I presume). This device has some on-board power rail switching which confused me the first time I used the board.

It's worth noting that flash erase will increase the current drain of the device - is your external PSU up to the job, and can you use an alternative?

Edit: Based on your feedback that stepping over the code in question causes the debugger to crash, whereas single-stepping does not, I think your issue is related to this question.

Step-over is implemented by using a breakpoint (and polling for halt state), whereas single-step is supported in hardware. This still doesn't explain why the debugger seems to be getting confused, but does allow for it being possible that the debugger is trying to access code (from flash) whilst the flash controller is active.

Based on these observations, I'd suggest you set a breakpoint after the erase, and try to avoid triggering this scenario.

  • Correct, it works fine but when I erase a block the usb connection to the debugger drops. I was using an unpowered usb hub so this seemed logical; however, directly connecting to the computer and using a different hub gives the same result.
    – netskink
    Mar 30, 2017 at 11:51
  • If you're running code whilst doing the flash access, you'll deadlock the AHB for a while. I imaging stepping in this scenario might be messy. stackoverflow.com/questions/3445598 has more. Mar 30, 2017 at 11:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.