HardFault on f_write() from FatFS

[ABatt.1]

Hi to all,

I'm facing with an hard fault when call f_write() or f_read() from FatFs library (R0.12c).

I'm able to mount SD card, create a file in write mode, write to it using f_puts().

As suggested, I use the HardFault_Handler:

void HardFault_Handler(void)
{
  /* USER CODE BEGIN HardFault_IRQn 0 */
	static volatile int _Continue;
 
	_Continue = 0;
 
	while(_Continue == 0);
	return;
  /* USER CODE END HardFault_IRQn 0 */
  while (1)
  {
    /* USER CODE BEGIN W1_HardFault_IRQn 0 */
    /* USER CODE END W1_HardFault_IRQn 0 */
  }
}

Once inside, I change the value of _Countinue to 1, and follow the execution with "Step into".

I found that the HardFault is caused by function validate() inside f_write().

I can't find the cause.

I use a STM32F103RCT, the project id generated in CubeMX. I try different Heap and Stack (0x800, 0x800) but the problem still remain.

So I have two questions:

1) How can I choose the best Heap/stack size and what is the greater value that I can configure ?

2) There is a way to identify the cause of HardFault ? I know what instruction generate it, but I don't know why.

Thanks to all.

[Walid ZRELLI]

Hello @ABatt.1​ ,

You can refer to the following example provided under our F1 Firmware package:

• Path: Projects\STM3210E_EVAL\Applications\FatFs\FatFs_uSD

Otherwise, take a look at this video. It may be helpful.

BeST Regards,

Walid

[Tesla DeLorean]

Suggested by whom?

A silent while() loop with no user output is going to give the tech support team a lot of details to work with.

Are you using an address that doesn't exist, exceeding a buffer, or doing something that's unaligned?

With builds on some systems you'll need to ensure you've allocated sufficient space for the stack usage the code you're running depends on for local/auto variables.

On Keil I'd suggest several KB more that the defaults.

[ABatt.1 · Accepted solution]

I found that the mistake is in f_write call.

I'm porting this code from a PIC18F, where the functio is called as:

f_write(&FileHandler, "Test", 5,0);

last parameter is the pointer where f_write saves the number of bit written. I don't use this information so NULL pointer is ok for PIC18.

But in SMT32 (and I think all ARM cortex) a NULL pointer cause the hard fault.

To resolve this simply I call f_write as:

f_write(&FileHandler, "Test", 5,&dummy);

where dummy is an unsigned int.

Rgards.