STM32 L4 HAL_FLASH Writes in one function but not another

Question

I am working with an STM32 L476RG evaluation board on a project. The goal currently is to utilize STM's mass storage library to write data to flash over USB. I've got the USB library working properly (simply reading and writing data from/to RAM as a start), but I've encountered a strange problem when using flash.

If I write to the flash in the STORAGE_Init_FS function (Using HAL_FLASH_Program(....)), I can write to the flash just fine. I clear the page, write arbitrary data to it, and it appears in the memory view of the debugger.

However, if I try to do the exact same thing in STORAGE_Write_FS (tried with line-for-line, the same code), then the flash operation returns an error and doesn't ever write any data.

Here are the relevant code portions:

{
  /* USER CODE BEGIN 2 */
    USB_Flash_Init();
  return (USBD_OK);
  /* USER CODE END 2 */
}

HAL_StatusTypeDef USB_Flash_Init() {
    __HAL_RCC_SYSCFG_CLK_ENABLE();
    __HAL_RCC_FLASH_CLK_ENABLE();
    /* Clear flash flags */
    HAL_FLASH_Unlock();
    __HAL_FLASH_CLEAR_FLAG(FLASH_FLAG_ALL_ERRORS);
    HAL_FLASH_Lock();

    HAL_FLASH_Unlock();
    HAL_FLASH_Program(FLASH_TYPEPROGRAM_DOUBLEWORD, 0x8080000, 0x0001);
    HAL_FLASH_Lock();
    return HAL_OK;
}

In the above code, the data 0x0001 is properly written to memory address 0x8080000. (The erase call is not there, but the page has been erased).

However, in the below function,

int8_t STORAGE_Write_FS(uint8_t lun, uint8_t *buf, uint32_t blk_addr, uint16_t blk_len)
{
  /* USER CODE BEGIN 7 */
    __HAL_RCC_SYSCFG_CLK_ENABLE();
    __HAL_RCC_FLASH_CLK_ENABLE();
    HAL_FLASH_Unlock();
    __HAL_FLASH_CLEAR_FLAG(FLASH_FLAG_ALL_ERRORS);
    HAL_FLASH_Lock();
    HAL_FLASH_Unlock();
    FLASH_PageErase(0, FLASH_BANK_2);
    HAL_FLASH_Program(FLASH_TYPEPROGRAM_DOUBLEWORD, 0x8080000, 0x0001);
    FLASH_PageErase(0, FLASH_BANK_2);
    HAL_FLASH_Lock();
  return (USBD_OK);
  /* USER CODE END 7 */
}

The data gets properly wiped (viewing the memory address through the debugger), but then never written, it remains 0xFFFFFFFF. I know some of the init stuff had already been done, but I wanted to be certain it wasn't the cause so I threw it in there as well. The only thing I can really think of would be the stack potentially not having enough space (unlikely with the massive amount of memory this thing has). In order to verify this wasn't the cause, I tried both taking my 2k buffer (not shown here) out of the function to no longer be a local variable, and increasing the stack and heap sizes to 0x4096 (excessive) in the RAM.ld.

Neither changed the behavior. Anyone I've spoken to has been at a loss as to the cause of this. What could I be doing wrong?

I do get two errors when I check HAL_FLASH_CheckError() (might not be the exact function name), 0xA0, which corresponds to HAL_FLASH_ERROR_PGS and HAL_FLASH_ERROR_PGA, programming sequence and programming alignment errors respectively. I'm not certain these errors are relevant, considering the actual function calls and setup are identical, only the scope is different.

If anyone has any advice, I'd be glad to hear it! Hopefully I'm just missing some control register or bit somewhere.

Answer 1

It appears that the actual issue is that the FLASH_PECR_ERASE (or at least that is what is called on the L0) is left set by the typical flash erase routines. This causes subsequent program attempts to be some odd and perhaps invalid mix of a program and erase operation. As mentioned deep in comments below I've previously seen this on an STM32L0, and it seems to be an issue with the STM32L4 here as well.

Original and apparently irrelevant ideas follow

Flash is writing fine in main() and wherever else I try, it's just in this USB write function that it fails.

Why can this not be done in an interrupt context? Both functions I've demonstrated are called in a USB interrupt managed by STM's libraries.

Taking at face value the (perhaps incorrect) belief that this is being called from an interrupt context, you most definitely cannot write to flash from an interrupt by ordinary means. Writing to flash is a very complex process, a real departure from ordinary chip operation that chips are supposed to hardly ever perform, and very time consuming too.

You'll need to cache the intention to perform a write (save the desire and the data), perform it later from the main loop, and then queue a success or failure response to send back through USB (ie, accept the data immediately, but don't reply if the write worked or not until you have completed it). Remember to make communication between the interrupt and main loop via safely atomic flags, or use an appropriately brief critical section to make a copy of anything non-atomic. You will probably need to lock out further modification of the data buffer from the interrupt until you have finished the write, if you cannot do that at the level of the USB buffer itself you may need to DMA from a USB buffer elsewhere in RAM and then write from there.

USB Mass Storage examples are very common. You can probably learn useful things about how to do the needed decoupling from an example backed by SPI flash rather than internal or from one for a different STM32 if the USB functional block has meaningful similarities in it's architecture with regard to buffering, etc.

If STORAGE_Write_FS() is really being called from an interrupt that is an unfortunate piece of example code. It may be that there are parts of the architecture of the example which are not yet sufficiently understood - if they give any example backed by actual non-volatile storage (vs faking it with a tiny bit of RAM) a detailed examination of that would be key.

Answer 2

Update: The problem was the usage of the FLASH_PageErase() function, which does not reset the proper control bits for the flash to allow writing again. It just coincided with the order of the function calls that I wasn't erasing the page until the second call.

I'm sure scouring the documentation will yield the relevant bits that need to be reset, but in my case I simply switched to the HAL_FLASHEx_Erase function. Leaving this here in case anyone runs into a similar issue.

Answer 3

I had similar problem on STM32L4P5, with HAL_FLASHEx_Erase(). It is essential to clear the flags before using the erase function.

FLASH_EraseInitTypeDef EraseInitStruct;
uint32_t PageError;

HAL_FLASH_Unlock();
__HAL_FLASH_CLEAR_FLAG(FLASH_FLAG_ALL_ERRORS);
HAL_FLASH_Lock();

//... fill EraseInitStruct here ...

HAL_FLASH_Unlock();

if (HAL_FLASHEx_Erase(&EraseInitStruct, &PageError) != HAL_OK)
{
    Error_Handler();
}