STM32G0 erasing bank2

[JRS]

I am using a stm32g0b1ret with stm32cubemx package 1.6.1 .

The symptoms are:

On deletion of pages I receive a signal 0 in the debugger, but the pages do get erased eventually. (I use HAL_FLASHEx_Erase)

On the first flash write I get an error with goes to hardfault - because the Flag CFGBSY is set. (I use HAL_FLASH_Program, with Doubleword).

A reset cures this, and then the writing happens without a further problem.

On the next erase the problem is repeated.

Questions:

I do not know, if this solves my problem, but it looks like there is an inconsistency between the ref man RM0444 and the cube-mx firmware/sample project.

CubeMX: Erasing pages in bank 2 assumes and asserts page number start from 0 to 127 for both banks and the choice of bank is done solely by the BKER bit.

Reference manual rev 5, page 71/page102 -> this looks like page numbers for bank 2 start at 256 (with a gap from last page 127 of bank1).

I have tried both ways, the pages get deleted in both cases, but also the error seems to stick. I have not found anything in the errata (I disabled the prefetch, to be on the safe side)

So, anyone got any experience with this?

Which would be the correct way to delete a page on bank 2?

[GwenoleB]

Hello @JRS​ 

Indeed, there is an inconsistency between RM and cubeFW.

The PNB register is 7-bits wide while currently in RM0444 this register is set to 9. So PNB register is in range of [0-127].

That's mean for each bank page number start from 0 to 127.

Then, to erase a page located into the Bank2, two points are mandatory:

• Set a page number within PNB range (0-127)
• Set the BKER bit to select the Bank2

 HAL_FLASH_Unlock();
 FLASH_EraseInitTypeDef EraseInitStruct = {0};
 EraseInitStruct.TypeErase = FLASH_TYPEERASE_PAGES;
 EraseInitStruct.Banks = FLASH_BANK_2; 
 EraseInitStruct.Page = 127; 
 EraseInitStruct.NbPages = 1;
 if (HAL_FLASHEx_Erase(&EraseInitStruct, &PageError) != HAL_OK)
 {
 
 }
 HAL_FLASH_Lock();

Moreover, can you share your option byte configuration and the IDE you use?

Best Regards,

Gwénolé

[JRS]

Hi Gwénolé,

thanks for the answer!

I use visual studio 2019 with visualGDB with an stlink v3 (current fw) for debugging.

I have not changed the option bytes from the factory state, yet. So cube-programmer reads for

RDP: 0xAA

BORF_LEV: 3

VORR_LEV: 3

UserConfiguration: all enabled, with NRST Mode to 3

PRCOP Protection:

x_STRT : 0x1ff 0x0803fe00

x_END: 0x0 0x08000200

Write Protection:

x_STRT : 0x7f 0x0803f800

x_END: 0x0 0x8000000

BOOT_LOCK uncheckd,

SEC_SIZE 0x0 0x00000000

SEC_SIZE2 0x0 0x00000000

So you already answered part of my question - meaning the cube-mx implementation is correct. Since the upper bits would get cut off, that would explaín, that I actually get the same result in both cases.

I did some more testing, and it seems that the problem might somehow be related to timing. With a while loop for checking the CFGBSY Flag after HAL_FLASHEx_Erase before the HAL_Flash_Lock it looked somewhat better. I have to test this some more, - SysClk is at 64Mhz.

Best Regards

Jan

[GwenoleB]

Hello @JRS​,

We are aware about limitation on Keil about setting a breakpoint when debugging.

When a breakpoint is set/reset, the CFGBSY bit changes value. CFGBSY locks the FLASH_CR register, and the only possibility is to add or remove wanted breakpoint and add or remove a random breakpoint.

The issue is when there is code doing Flash manipulation. CFGBSY toggling makes the routine fail.

It seems that we have a similar behavior with CubeIDE and we are looking if it occurs due to the same root cause.

I'll come back quickly on this topic.

Best Regards,

Gwénolé

[JRS]

Just to close this case. I was not able to recreate the problem on the NucleoBoard. There the writing and erasing could be done without problem using stm32cube ide. When I debug on visualGDB and my custom board I however still have it.

My internal workaround was, to add an additional delay after accessing the HAL_FLASHEx_Erase and HAL_FLASH_Program Function. It should not be necessary, as there are internal delays/ready checks, but that is the change that worked for me.