STM32H563 Flash Erase Program sample fails in Keil

[Ehow]

I create sample code for FLASH Erase Program on both mdk arm and stm32cubeide. Using the sample hardware(stm32h563ZITx develop board), the sample code runs correctly on stm32cubeide, but will enter Error hander when doing Flash operation in keil debug mode.:

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

{

while (1)

{

Error_Handler();

}

}

The C code for two project are the same. The only difference is IDE.

This issue only occurs in debug mode. If I download the code into flash without entering debug mode, the code will successfully run.

By debugging, I find FLASH_NS->NSSR was set as 0x0040000 when I get into the main function of debug mode in Keil,

while FLASH_NS->NSSR is 0 when I debug on stm32cubeIDE. Then I try to manually clear FLASH_NS->NSSR by setting

FLASH->NSCCR as 0x40000.But there will be following bug.

[KDJEM.1]

Hello @Ehow and welcome to the community 🙂,

I think that the issue of Flash Erase Program failing in Keil is due to breakpoints. 

Could you please try to disable this behavior by following the instructions provided  here.

Please let me know if the issue is solved.

Kaouthar

[Ehow]

Hi @KDJEM.1 , thank you for your reply.

1. I removed all my breakpoints and it could avoid dropping into ErrorHandler. However, if I need breakpoint for DEBUG purpose, what should I do?

2. I see your link for instruction of SBC. Then I create "debug.ini" with "SBC CLEAR *" in it. And I load it as initialization file of debugger in Keil IDE. Do I need to add extra lines? When I add "debug.ini" and add breakpoint in my code, I can still get into ErrorHandler.

Thanks,

Yihao (pronounced as "E - How")

[KDJEM.1 · Accepted solution]

Hi @Ehow Yihao,

Thank you for this update.

Are you using FLASH_EraseProgram example?

To check the issue, could you please share you project and indicate where you need to add breakpoint in the code?

Which version of Keil do you use?

Note that, the fail issue is due to the fact that, when setting HW breakpoint, uVision attempts to set a software breakpoint first (since HW breakpoints are sparse). If the writing of the breakpoint instruction fails it reverts to setting a HW breakpoint. There is a command that allows you to tell the debugger where and how uVision shall handle breakpoints in different memory regions. This default behavior can be disabled via the command line using the SBC command.

Disable the attempt to write to Flash example: SBC 0x08000000, 0x0807FFFF, 0 // Disable usage of SW Breakpoints for the address range.

This command should be added to an INI file and configured for inclusion in the "Options for Target" dialog in the Debugger tab.

Thank you.

Kaouthar

[Pavel A.]

HAL_FLASHEx_Erase returns status value and SectorError that can be helpful to understand the reason. 

[Ehow]

Hi @KDJEM.1 ,

Thank you very much for your reply! Now my problem is solved!

My previous error is that I write "SBC CLEAR *" in my ini file, for I am not familiar with those arm commands.

I guess maybe "SBC CLEAR" is used to clear the existing breakpoints, not disabling future SW breakpoints.

Thanks,

Yihao

[Ehow]

BTW, if flash has already been locked. We need to add FLASH->NSCCR = 0x0040000; // In case flash was locked before initializing icache or any flash operation, in order to clear the error flag.