Writing to flash generates a HardFault

[ErX]

Hi,

I'm busy with my own BootLoader. I can erase the flash, required to store the program. But writing to the flash causes a HardFault. (I also write to flash in my application to store the configuration. That seems to work, so (normally) I can write to the flash without any problems).

My routine looks as follows (msg.Data is the received information from my PC. The contents look fine):

  HAL_FLASH_Unlock();
  uint64_t* pData = (uint64_t*)&msg.Data;
  while (m_CurrentAddress < tempEndAddress)
  {
    HAL_FLASH_Program(FLASH_TYPEPROGRAM_DOUBLEWORD, m_CurrentAddress, *pData);
    m_CurrentAddress += 8;
    pData++;
  }
  HAL_FLASH_Lock();

 The debugger shows this information:

I do not know how to (further) debug this information.

Thanks in advance.

Greetings,

ErX

[ErX]

If I change the messing around with the pData pointer, and just use data like this:

  HAL_FLASH_Unlock();
  uint8_t nIndex{};
  uint64_t Data{};
  while (m_CurrentAddress < tempEndAddress)
  {
    memcpy(&Data, &msg.Data[nIndex], sizeof(Data));
    HAL_FLASH_Program(FLASH_TYPEPROGRAM_DOUBLEWORD, m_CurrentAddress, Data);
    m_CurrentAddress += 8;
    nIndex += 8;
  }
  HAL_FLASH_Lock();

It works just fine. (even though I do not really understand the big difference).

[Ozone]

> I do not know how to (further) debug this information.

The first recommendation is to switch to "instruction stepping", i.e. debugging on machine code level.
Doing so right before the "C" code line the hardfault hits is sufficient.
Watching the registers and associated values, this should give you a clue.

Second / alternative recommendation is to check the fault registers in the SCB block of the MCU.
They indicate the source of the fault.

[Saket_Om]

Hello @ErX 

Please refer to the article below to debug the HardFault:

How to debug a HardFault on an Arm® Cortex®-M STM3... - STMicroelectronics Community