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]

MPU enabled ?

Or another unhandled/escalated fault ?

I would check the SCB registers for fault reason & location.

Although, I don't have specific experience with the H7.

[sivaram]

MPU is not enabled.

[sivaram]

Unaligned bit is set in UFSR register.

[Uwe Bonnes]

I do not find a hit when searching for UFSR in RM0399.

[sivaram]

It is in programmers manual PM0253.

[Tesla DeLorean]

Custom board? Which H7 specifically?

Check clock speeds.

Check supplies and VCAP pins/caps.

Check Flash wait states.

Check length a multiple of 4.

Keil, IAR or GCC?​

[AB.17]

I have STM32H750VB on desk and I have dumped flash with 0 issues:

volatile uint32_t *d1 = 0x08000000;
do{
volatile uint32_t temp = *d1;
d1++;
}while(d1<0x080FFFFF);

Used keil, no HAL, clock is 400 MHz. Afaik STMH7s have sane default setting of flash latency, so it runs with highest clock without touching.

As I understand OT has some other soft already running so it wouldn't matter.

At what exactly instruction it breaks?

HAL usage?

[sivaram]

Just copy pasted this code,

The hardfault occurs at

volatile uint32_t temp = *d1;

The address in d1 is 0x80029d0 at the time of hardfault, another time is 0x800332c... I have no other code other than this after the initialization.

[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.

[sivaram]

Nucleo-h743zi

gcc.

Length and address increments is always a multiple of 4.

The processor runs at 64mHz, with a flash latency set to 0. Changed the flash latency to 4. Still the result is same.

[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?

[bnguy.1]

It seems to be caused after writing to the sector.

I'm flashing the same way every time but apparently, in some cases, the write results in an (ECC?) error, that generates hard-faults if read. STM32CubeProgrammer will also fail to read the sector, and must be erased in order to recover. HAL always returns OK.

HAL_FLASH_Unlock();
if (HAL_FLASH_Program(FLASH_TYPEPROGRAM_FLASHWORD, 0x081E0000 + (32*fw), (uint32_t)(pSrcBuffer)) != HAL_OK)
{
		// ERROR!
 while ( 1 );
}
HAL_FLASH_Lock();

[fb_it]

I had the same hard fault from random flash addresses when reading. It happened, when I wrote a flash word (32 bytes) with HAL_FLASH_Program, to an address in flash to which I already wrote, but with erasing the sector first with HAL_FLASHEx_Erase. Then the next read caused the hard fault. But not necessary at the location where I wrote. I guess something related to ECC. Tested with a NUCLEO-H723ZG board.

[Gary_Zhang]

Hi, 

Did you fix this issue?

I also have the same situation recently. Read the Flash sector after writing will end up with a hard fault. 

It seems many folks see this kind of issue, any one from ST to look into it?

[NAndreadakis]

Hi,

I have the same problem with a STM32WLE5CC6 version.

I use some part of the flash to read and write for storing critical data during hardfault or power down. 

Write now some of the production devices have this problem... I write a code to make a dump of the memory and i get the exactly same result. The device is restart / get in hardfault, after reading couple of pages.

Looking that thread looks like the problem is big. Now from my statistics from production devices this problem happened to about 4 in 3000. Hope not to see the problem on other devices.

Also looking for a way to recover the device from that problem. ( Probably erasing the sectors ? i don't know)

 

Best regards and patience,

Nikos

[Tesla DeLorean]

Would probably watch writing .ELF or .HEX as these have voids, vs a .BIN without.

Writing portions of flash lines.