Delete (mass erase) flash bank 2 on STM32F429II

[phb]

Posted on November 27, 2014 at 14:06

I have a STM32F429II with 2 x 1MB flash memories. It supports Read-While-Write on the flash banks. I have written code to write/read to the flash memory bank 2 and my application is on the flash bank 1. I have also written function to delete a sector and to do a mass erase on the whole bank 2. The sector delete function works, but the mass erase aborts the debugging process and it does look like it does not work.

I am using the HAL STM32F4 library version 1.3.0. The test code I have written writes some data to the start of the first and second sector (sector 12 and 13)of flash bank 2. I am watching the start of the memory of both sectors in Keil uVision 5 using the memory windows and then try to execute the flash bank 2 mass erase, but then the debugging aborts and the memory seems to get random value just before it quits. This is the code:

#include ''stm32f4xx_hal.h''
void main (void)
{
FLASH_EraseInitTypeDef eraseInit;
uint32_t error;
//Reset of all peripherals, Initializes the Flash interface and the Systick.
HAL_Init();
//Configure clock and flash latency.
SystemClock_Config();
//Unlock flash access.
HAL_FLASH_Unlock();
//Write a word to the start of sector 12 and sector 13 of bank 2.
HAL_FLASH_Program(TYPEPROGRAM_WORD, 0x08100000, 0x12345678);
HAL_FLASH_Program(TYPEPROGRAM_WORD, 0x08104000, 0x87654321);
//Lock flash access.
HAL_FLASH_Lock();
//Configure mass erase parameters.
eraseInit.TypeErase = TYPEERASE_MASSERASE;
eraseInit.Banks = FLASH_BANK_2;
eraseInit.VoltageRange = VOLTAGE_RANGE_3;
//Unlock flash access.
HAL_FLASH_Unlock();
/*** This is the line that aborts the debugging... ***/
HAL_FLASHEx_Erase(&eraseInit, &error);
//Lock flash access.
HAL_FLASH_Lock();
//Infinite loop.
while(1)
{
}
}
void SystemClock_Config(void)
{
RCC_OscInitTypeDef RCC_OscInitStruct;
RCC_ClkInitTypeDef RCC_ClkInitStruct;
RCC_PeriphCLKInitTypeDef PeriphClkInitStruct;
__PWR_CLK_ENABLE();
__HAL_PWR_VOLTAGESCALING_CONFIG(PWR_REGULATOR_VOLTAGE_SCALE1);
RCC_OscInitStruct.OscillatorType = RCC_OSCILLATORTYPE_LSI|RCC_OSCILLATORTYPE_HSE
|RCC_OSCILLATORTYPE_LSE;
RCC_OscInitStruct.HSEState = RCC_HSE_ON;
RCC_OscInitStruct.LSEState = RCC_LSE_ON;
RCC_OscInitStruct.LSIState = RCC_LSI_ON;
RCC_OscInitStruct.PLL.PLLState = RCC_PLL_ON;
RCC_OscInitStruct.PLL.PLLSource = RCC_PLLSOURCE_HSE;
RCC_OscInitStruct.PLL.PLLM = 8;
RCC_OscInitStruct.PLL.PLLN = 336;
RCC_OscInitStruct.PLL.PLLP = RCC_PLLP_DIV2;
RCC_OscInitStruct.PLL.PLLQ = 7;
HAL_RCC_OscConfig(&RCC_OscInitStruct);
RCC_ClkInitStruct.ClockType = RCC_CLOCKTYPE_SYSCLK|RCC_CLOCKTYPE_PCLK1
|RCC_CLOCKTYPE_PCLK2;
RCC_ClkInitStruct.SYSCLKSource = RCC_SYSCLKSOURCE_PLLCLK;
RCC_ClkInitStruct.AHBCLKDivider = RCC_SYSCLK_DIV1;
RCC_ClkInitStruct.APB1CLKDivider = RCC_HCLK_DIV4;
RCC_ClkInitStruct.APB2CLKDivider = RCC_HCLK_DIV2;
HAL_RCC_ClockConfig(&RCC_ClkInitStruct, FLASH_LATENCY_5);
PeriphClkInitStruct.PeriphClockSelection = RCC_PERIPHCLK_RTC;
PeriphClkInitStruct.RTCClockSelection = RCC_RTCCLKSOURCE_LSE;
HAL_RCCEx_PeriphCLKConfig(&PeriphClkInitStruct);
HAL_RCC_MCOConfig(RCC_MCO1, RCC_MCO1SOURCE_PLLCLK, RCC_MCODIV_2);
}

#stm32f4 #flash

[waclawek.jan]

Posted on November 28, 2014 at 10:00

The debugger is not a magic spying glass showing the innards of the chip without any impact on its functioning. It *is* intrusive. The on-chip part of it is attached to the processor core, and accesses the peripherals - including FLASH - through the processor's buses.

As the processor is stalled when trying to access the FLASH, I guess the same applies for the on-chip-debugger. My guess is, that as it tries to read the FLASH during erasing, it stalls, and as bulk erase lasts really long, the debug adapter (the ''JTAG-thingy'') or the software in PC times out and throws any error you might see. While doing that, trying to recover, it resets the chip, and this might interrupt the FLASH erasing (?). Try not to look at the FLASH while erasing and please report back. JW