2021-11-06 01:33 AM
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.
Solved! Go to Solution.
2022-01-23 10:04 AM
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.
2022-01-03 07:44 AM
Hello @ABatt.1 ,
You can refer to the following example provided under our F1 Firmware package:
Otherwise, take a look at this video. It may be helpful.
BeST Regards,
Walid
2022-01-03 11:34 AM
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.
2022-01-23 10:04 AM
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.