FAQs
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 

Using a STM32H745/755 device and Cube Programmer in DFU mode connected via USB and trying to erase flash memory via Cube Programmer..

FArms.1
Associate II

‎2022-07-20 07:19 PM

I've noticed that if the option byte for the CM7 boot address is set to 0x1FF0 (boot into bootloader), the Cube Programmer cannot erase the flash memory. If I change that option byte to 0x0800, the flash memory erases.

I can erase and program the flash memory fine using ST-LINK independent of the CM7 boot address setting. But I want to be able to erase flash memory via DFU with the bootloader with the boot address set to 0x1FF0 for the CM7 core.

Is there something that limits the bootloader in DFU mode from erasing flash memory if the CM7 boot address is set to 0x1FF0?

I've verified that no write protection is set and the memory is not protected.

0 Kudos
2 REPLIES 2
FBL
ST Employee

‎2022-10-06 09:10 AM

Hello @FArms.1​, 

Here is a screenshot after full erase using DFU,

CM7 boot address is set to 0x1FF0.

My working environment:

Board STM32H745-DISCO

STM32CubeProgrammer V2.11.0

Can you specify what environment details you need?

Could please precise your working environment?

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.

0 Kudos
FArms.1
Associate II

‎2022-10-06 01:12 PM

Hello.

I had found a workaround in our system where I no longer need to program the boot option bytes when re-programming. So, I never tried this again since that early date.

I did go back to what I think is the code I had when the issue occurred. I tried to re-create the issue but I couldn't get it to happen again. I was able to successfully program with cube programmer with the boot address set to 0x1ff0. So, I'm not sure what I was doing differently when I had the issue. There are so many different variables when DFU programming.

I was using a Nucleo 755 board as a development system prior to actual hardware. I had the board set to external power and was running off a 7V supply. I was keeping the ST-LINK connection unplugged and just using the DFU usb port. I'm using the libusb driver. I am using cube programmer 2.11.0. I was setting the cm7 boot address to 0x1ff0 programmatically (via python usb) so that if the programming crashed, it would boot back into DFU. I just ran the same code on that old Nucleo board and it seems to work now. So, I'm not sure what else was different back then. I haven't been using DFU in several months now so many things have changed since then.

If I run into this issue again when I get back to DFU, I can update this post.

0 Kudos
Top