Hard Fault Writing Flash

[tommelou]

Posted on March 28, 2014 at 16:11

Hi,

i'm trying to create a bootloader into the component STM32f106RDT with 384KO of Flash.

I have mapped the memory like this:

0x08000000 - 0x0802FFFF for main software (first binary)

0x08030000 - 0x08030FFF for bootloader that will copy second part to first part

0x08031000 - 0x0805FFFF for the temp binary (second binary)

 My binary file size is 60KO. So I can't copy my new binary file into the RAM, this is why I will use the secondary party of memory flash.

I'm receiving datas by serial com at 115200bps with interrupt by packet of 400bytes.

The page size is 2048bytes. And i need

I erase well all needed pages.

My problem is that i'm writing well the first 102 frames of 400bytes into the flash at adress 0x80301000 but after this the chipset go in the Hard Fault interruption (

HardFault_Handler ). I can't follow the call stack because there is'nt.

I need to copy 50 more frames.

The USART interrupt is low at 5, and I have a scheduler with higher priority.

I'm using Keil environment with ULINK2.

Do somebody have a solution or way to analyze this problem?

Thank You

#hard-fault-stm32

[Tesla DeLorean]

Posted on March 28, 2014 at 16:25

Use a proper Hard Fault Handler, Google : Joseph Yiu Hard Fault Handler

Confine the problem, knowing processor state, register state, and assembler instructions being used.

Make sure you don't have any interrupt code that might jump into the erased, or written too portions of flash.

Make sure you are not writing, or reading, memory locations outside the defined ranges. That your stack is adequately sized to hold any local/auto variable, that the stack is not getting corrupted and you're not jumping to any 32-bit code.

Keil by default has a VERY small stack allocation, observe what you're using, and what's defined in startup_stm32fxxx.s

[tommelou]

Posted on April 01, 2014 at 11:53

Thank You Clive1,

I have implemented the method ''Joseph Yiu Hard Fault Handler''.

I can see that the caller comes from a function of a scheduler of the ST Motor Control Library. The function is ''static uint16_t RVBS_CalcAvVbus(CVBS this);'' in the task

''void TSK_SafetyTask(void)''.

I have tried to write in the flash 0x1000 address further to see if it come from the Flash. But I writing the same lenght of frame 102. So it seem like there is a timout i'm not refreshing in the ST Library.

My problem is not solved.

[tommelou]

Posted on April 01, 2014 at 16:34

I have found the problem, i was probably writing the flash during an acces.

It's because in the stm32f10x_flash.c there is a bug, the bit PG is asking to toogled but the status is never really checked, so in the function

FLASH_Status FLASH_ProgramHalfWord(uint32_t Address, uint16_t Data)

when     ''FLASH->CR |= CR_PG_Set; ''

add the line

    ''while( FLASH->CR & CR_PG_Set!=CR_PG_Set);  /*check the status*/''

and when Disable the PG Bit

    ''FLASH->CR &= CR_PG_Reset;''

add the line

     ''while((FLASH->CR&(~CR_PG_Reset))!=0x00000000); /*check the status*/''

I hope this will help sombody else, and may be ST shall add this.

[Tesla DeLorean]

Posted on April 01, 2014 at 16:56

may be ST shall add this.

The libraries are not designed to be thread safe, what circumstance wouldn't the OR/AND set/clear the bit, and how would sitting in an infinite loop when the bit isn't set remedy this?

More to this issue.

[tommelou]

Posted on April 02, 2014 at 17:11

In fact I had an other problem, I was reading my datas to write into the flash from a big aligned struct. I just recopy struct aligned in a tab of bytes then no more hardfault.

I don't really know why it happend so lately, not easy to debug, but REALLY solved.

Thank you clive1.