AzureRTOS FileX hard fault in _fx_file_create at _fx_directory_search

[Michael_GetElectronic]

Hello everyone! 

I'm working on an application using AzureRTOS and FileX, however, I'm getting a hard fault that I can't pin down.

Here is a screenshot of the variable states when entering _fx_directory_search (in middleware fx_directory_search.c) which causes the hard fault. It seams to occur as the function is called. (Not sure why the resolution is bad but don't think there is anything I can do about it I'm sorry!)

I'm seeing a lot of 0x0 in the function arguments.

media_ptr	FX_MEDIA *	0x0	
name_ptr	CHAR *	0x0	
entry_ptr	FX_DIR_ENTRY *	0x0	
last_dir_ptr	FX_DIR_ENTRY *	0x0	
last_name_ptr	CHAR **	0x200012a8 <fx_byte_pool_buffer+408>	
i	ULONG	4025479151	
n	ULONG	1627389952	
found	UINT	134272988	
status	UINT	4025479151	
v	UINT	134276061	
j	UINT	10	
cluster	ULONG	536875464	
next_cluster	ULONG	4025479151	
directory_size	ULONG64	2305863900471563680	

And a screenshot of the states before entering the above function:

I take note of:

name_ptr	CHAR *	0xffffffff <error: Cannot access memory at address 0xffffffff>	

But also many of the arguments are non 0x0.

I'm really not too sure how to debug a hard fault like this in code that I have not got the foggiest on how it works. Even the variable names are confusing between scopes, the *name_ptr from _fx_file_create is not even the same as the *name_ptr  in _fx_directory_search, so confusing for a young engineer like myself. 

I would greatly appreciate any help and hopefully learn something.

Cheers,
Michael

[Saket_Om]

Hello @Michael_GetElectronic 

If you pass an uninitialized, the function will try to access invalid memory, causing a hard fault.

[MFARH.1 · Accepted solution]

Hello @Michael_GetElectronic ,

The hard fault occurring in the _fx_file_create  function of AzureRTOS FileX is often caused by a stack overflow or improper handling of pointers and memory in this critical section.

This type of error is generally due to insufficient stack size or invalid pointers. Increasing the CSTACK size in the linker configuration file is likely to resolve this issue.

Regards,

Maher