STM32F105 flash erase problem

[yury]

Posted on June 16, 2017 at 16:56

Hello!

Got a weird problem with STM32F105R8T6 chip

While the same code, compiled and running on 

STM32F103R8T6, works ok

Program size is 17 kB as can be seen from map file:

AHBPrescTable 0x0800473a Data 16 system_stm32f1xx.o(.constdata)

Region$$Table$$Base 0x0800474c Number 0 anon$$obj.o(Region$$Table) Region$$Table$$Limit 0x0800476c Number 0 anon$$obj.o(Region$$Table) stTac_TO 0x20000028 Data 8 stm32f1xx_it.o(.data)

I'm attempting to erase flash page located well above the program at 32 kB with the following code

HAL_FLASH_Unlock();

__HAL_FLASH_CLEAR_FLAG(FLASH_FLAG_EOP | FLASH_FLAG_WRPERR | FLASH_FLAG_PGERR); EraseInitStruct.TypeErase = TYPEERASE_PAGEERASE; EraseInitStruct.PageAddress = (uint32_t)(0x08008000); EraseInitStruct.NbPages = 1U; EraseInitStruct.Banks = FLASH_BANK_1; HAL_FLASHEx_Erase(&EraseInitStruct, &SectorError); HAL_FLASH_Lock();

Flash content erases ok, and I can write new data 

HAL_FLASH_Program(TYPEPROGRAM_HALFWORD,

(uint32_t)(0x0800C000)

, const1);

The data is read back ok

Application runs ok, however it halts after reset

If I write protect pages 32...35 , the data is not erased, the application works normally after reset

Weird thing however is that there's no application data or code above 0x0800476C as can be seen from the MAP file

Am I missing something?

#stm32 #flash-erase #page-erase #flash

[Tesla DeLorean · Accepted solution]

Posted on June 16, 2017 at 18:43

>>

Application runs ok, however it halts after reset

But halts where? Do you have a Hard Fault handler that output some diagnostic information, or telemetry to narrow that down a bit?

Do these parts share a common memory size, and flash sector sizes? Is the code built with the correct defines describing the processor?

Set the IROM size to constrain the image within 32KB, and report errors if it doesn't

[yury]

Posted on June 16, 2017 at 19:40

Thank you, your advice worked

I moved the data to be erased/reprogrammed to the last page and limited IROM to one page less than available , this worked perfectly

What I don't understand however is that if I don't limit IROM, but create a placeholder array like this

#define LOC1   ((uint32_t)(0x08010000)-(uint32_t)FLASH_PAGE_SIZE)

__attribute__((at(LOC1))) static const uint16_t placeholder[(FLASH_PAGE_SIZE/(sizeouf(uint16_t)))]

linker will output out of memory error , though MAP file shows that the array size is 2048 , and it resides at 0x0800f800 , like intended

The reason of the halt was CubeMX-generated startup code (latest version), which contains counter that's not initialized explicitly (anywhere in running code)

static uint32_t HAL_RCC_CAN1_CLK_ENABLED=0;

. Startup code for STM32F103 part doesn't have such a problem, that's why the code previously worked in the other chip. 

Interesting that locating the erased page anywhere between the end of the code and the end of the memory modified the variable anyway, I have no good explanation of this

[bruce239955]

Posted on January 09, 2018 at 14:13

Hi.

I've got a similar problem on an STM32F217 where my bootloader  code will halt after an NVIC_SystemReset if the bootloader had erased any portion of the FLASH prior to the reset. It is only erasing sectors outside the bootloaders FLASH memory.

I'm on the latest version of CubeMX 4.23.0 and FW 1.7.0

Which code had the un-initialized counter - probably worth checking in my code just in case.

Ta