cancel
Showing results for 
Search instead for 
Did you mean: 

Why would FLASH_FLAG_PGPERR and FLASH_FLAG_PGSERR be set after a successful flash write, and at power-up before any flash write operations?

SHers
Associate III

I've written a flash-based bootloader for the STM32F4 using the latest STM32CubeMX tool and its HAL libraries. I've avoided all the usual pitfalls (it's not my first bootloader), and my code works reliably. I'm not erasing my bootloader segment, writing to the wrong address, or failing to account for the instruction pipeline stall that a flash write causes. So far, so good.

However, one problem I encountered was that on power-up, BEFORE any flash operations were done, I would generally find that the flash alignment and parallelism error flags were set. Moreover, during the course of writing a 200K byte image to flash in small chunks, I randomly encounter these error flags after successfully writing data to the last byte in a 256-byte page (this happens at various places in mid-sector, not at the sector boundary).

Specifically, the call to HAL_FLASH_Program() to write a byte at a 256-byte boundary fails because the PGP and PGS flags got set after the end of the last (verified successful) call to HAL_FLASH_Program() for the immediately-prior flash address and the start of the call to HAL_FLASH_Program() for the new address on the boundary.

My flash write algorithm writes 256 bytes at a time with a sequence of calls to HAL_FLASH_Program(FLASH_TYPEPROGRAM_BYTE...), after which the program goes off and calls LwIP_update(), then comes back to write the next page. Inspection of flash contents shows that the data DID get written to flash, and HAL_FLASH_Program() returns a success code consistent with that. After the overall flash operation is done, I go back and MD5sum the downloaded flash area, and it's always bit-perfect. No other processes are messing with flash, and the MCU supply voltage of 3.3V is compatible with byte-wide flash writing, and the main clock frequency of 144 MHz is within spec. The source of these errors is a mystery.

My temporary solution is to call __HAL_FLASH_CLEAR_FLAG(FLASH_FLAG_OPERR | FLASH_FLAG_WRPERR | FLASH_FLAG_PGAERR | FLASH_FLAG_PGPERR | FLASH_FLAG_PGSERR) before each flash write, and pay attention to any failure code returned by HAL_FLASH_Program. This seems to have fixed the problem, but I remain suspicious. Suggestions?

11 REPLIES 11
ROKAM.1
Associate

In my case, usbd_conf.c (generated by cubeide) causes this problem.

 In USBD_LL_Init(), the following functions are executed after initialize "hpcd_USB_OTG_HS".
HAL_PCDEx_SetRxFiFo(&hpcd_USB_OTG_FS, 0x80);
HAL_PCDEx_SetTxFiFo(&hpcd_USB_OTG_FS, 0, 0x40);
HAL_PCDEx_SetTxFiFo(&hpcd_USB_OTG_FS, 1, 0x80);

 

I fixed as follows, 
HAL_PCDEx_SetRxFiFo(&hpcd_USB_OTG_HS, 0x80);
HAL_PCDEx_SetTxFiFo(&hpcd_USB_OTG_HS, 0, 0x40);
HAL_PCDEx_SetTxFiFo(&hpcd_USB_OTG_HS, 1, 0x80);

 

Calling `HAL_IWDG_Refresh(&hiwdg)` before `MX_IWDG_Init()` caused this error to happen for me. which is crazy!