Hard Fault when reading flash

[sivaram]

I am working to generate the CRC for the flash memory, During this I am facing hard fault when the CRC module tries to read from certain flash locations, to debug it I made a small loop which assigns the value of each 4 byte. I found that reading at certain locations results in hardfault.

I tried with different starting address, I found that

when starting address is 0x08000000 hardfault occurred at 0x08000440

when starting address is 0x08001000 hardfault occurred at 0x0800144c

when starting address is 0x08004000 hardfault occurred at 0x080044cc

uint32_t *d1 = 0x08000000;
while(length){
      uint32_t temp = *d1;
      d1++;
      length -= 4;
}

Any Idea of what is causing this issue?

[Ozone]

> volatile uint32_t temp = *d1;

> The address in d1 is 0x80029d0 at the time of hardfault, another time is 0x800332c...

The causative assembler instruction and the relevant register values would be interesting.

[AB.17]

Hmm, I've injected those addreses into register sourced by ldr and no issues. :|

Does your dissassembly really uses proper addreses? Still may be compiler difference. I don't have gcc toolchain installed right now.

[sivaram]

I created a new project and the above code snippet works fine without issues. compared both the snippets the suspicious difference I found is, in the project where I had the hardfult the vector table was moved to sram in system_stm32h7xx.c file(#define VECT_TAB_SRAM), Once I commented it out its working fine. I could not understand how this causes hardfault at random flash address?

[Tesla DeLorean]

You've got some interrupt faulting. You haven't shown assembler or registers at faulting point, so hard to debug through the keyhole.​

[Ozone]

The vector table has a 2^8 address alignment requirement (if I remember correctly). A word address (32 bit) is not sufficient.

[AB.17]

Check linker output file - what addressed are used for interrupts routines and are they coherent with the addreses of offsetted vector table. So the crash could be caused by sth like debug exception, not the code itself.

[sivaram]

I created a new project and the above code snipped worked without any issues, on comparing the old and new ones, I found that old one uses the RAM for vector table enabled by #define VECT_TAB_SRAM in system_stm32h7xx.c file, once I commented out the old one also worked fine. Could not understand how this causes hard fault?

[sivaram]

Looks like the change has no effect in moving the vector, the map file shows the following output, irrespective of defining the flag. This could have caused the issue.

          0x0000000008000904       0x2 Core/Startup/startup_stm32h743zitx.o

               0x0000000008000904               RTC_Alarm_IRQHandler

               0x0000000008000904               EXTI2_IRQHandler

               0x0000000008000904               TIM8_CC_IRQHandler

               0x0000000008000904               HRTIM1_Master_IRQHandler

               0x0000000008000904               UART8_IRQHandler

               0x0000000008000904               SPI4_IRQHandler

               0x0000000008000904               TIM1_CC_IRQHandler

               0x0000000008000904               BDMA_Channel6_IRQHandler

              ........

[bnguy.1]

Did you find the cause of this issue? I"m seeing the same thing.. just assigning a pointer to the sector start, and then reading, causes the hard fault... or sometimes it reads 0, but the data flashed is not 0 :

	uint32_t *pFlash = (uint32_t*)(0x81e0000);
        uint32_t ulData;
        ulData = pFlash[0];
 

Interestingly, if I power off the stm32h7 disco, the read works again, but can get it to fail by, unlock, write data then locking again. Everything returns HAL_OK, yet the very next read of the flash causes the hard fault.

[Pavel A.]

Is data cache enabled?