Skip to main content
ABatt.1
Associate III
November 6, 2021
Solved

HardFault on f_write() from FatFS

  • November 6, 2021
  • 3 replies
  • 2382 views

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.

This topic has been closed for replies.
Best answer by ABatt.1

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.

3 replies

Walid ZRELLI
Visitor II
January 3, 2022

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
Guru
January 3, 2022

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.

Tips, Buy me a coffee, or three.. PayPal Venmo (See Profile) Up vote any posts that you find helpful, it shows what's working..
ABatt.1
ABatt.1AuthorBest answer
Associate III
January 23, 2022

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.