Hard Fault on function start - but cannot debug

[AScha.3]

I have a problem, but dont know, how to solve...

when this function ( mp3dec_decode_frame(..) ) is used, get hard fault. ok, but cannot debug , because no step into function is possible, hard fault is always next step.

Now the prerequisites : this function i used to decode MP3 in my H743 project, no problems.

then copied to this H563 project, but now using rtos Azure (because forced to use this by STM)…

and now : not working anymore, even cannot debug, what happens there, because first is : jump to hard fault.

So maybe the stack is in nirwana, but i cannot see (understand ARM assembler) anything, that leads me to solve the problem.

See , here is the debug at starting the function:

disassm shows here:

(i see no problem...) stack is in mem:

and this seem ok:

so: how to find the reason for this hard fault ?

next step ...hard fault :

cpu then:

[AScha.3 · Accepted solution]

Yes, seems working now . 😎

Problem was (probably) stack overgrown in the area of the usbX stack area...

The mp3 decoder eating up 23KB stack, so i was just lucky to make a test with set to 24KB, then no hard fault.

Other problem with sometimes error was the hardware: lines to sdcard too long (15cm) , curiously the fatfs i tried had less problems , or no problem at first. But after some days - also errors sometimes. Then i guessed, maybe its not the software and give fileX another try. With short wires (25mm) now reads at 200Mbit, about 20MB/s .

I work on a nucleo-H563 with this, and agree: >> THREADX - it's super sensitive about the memory.

+ it should tell about, not just crash. 😬

I thing there is a stack monitoring - but dont know, what it is doing...can be set in tx_user.h

#ifndef TX_USER_H
#define TX_USER_H

/* USER CODE BEGIN 1 */
#define TX_ENABLE_STACK_CHECKING
/* USER CODE END 1 */

+

>  I moved all file operations to my main application thread 

I had same idea , named it "tx_app_main" , to know where i am  🙂

just my settings:

FileX   20KB pool   , 4K stack. exfat enable , MAX_CACHE_SIZE_NB_BIT 9 ; map_size 128;

MAX_FAT_CACHE_NB_BIT 4 ; MAX_SECTOR_CACHE_NB_BIT 4 ; 

usbX   32K pool  , 24K sys stack, 4K app stack.

threadX 60K pool , 24K app stack .

and added small test thread : 1K stack . (blink LED , to "see" multitasking is running )

if you know better settings, tell... 🙂

[HTD]

Holly cow, I'm surprised it works wit so little stack for your file access thread. I gave my file access thread 128KB and it still crashes depending on the target file system. I guess there's something terribly wrong with my code. It's peculiar that the media and file handles are pretty low in the memory, but my local variables are on the stack limit when it crashes. It seems like something is pumping the stack there. I probably gave it more than enough memory, something else must be wrong.

That's the first time the function is called here.

The offending code seems to start here:

Maybe it's related to media statistics. And AFAIK it's free space evaluation, number of files and that sort of thing. Maybe it's broken? IDK, I'll just try to disable and see what will happen. I noticed that my tests use to pass when performed on empty media, and crash when I add some files to them (I just copy a bunch of my sources for testing).

BTW, my crash occur on `fileExists` function, so it shouldn't even need much memory to complete, just a few sectors for directory entries. I'm sure it uses more than one. One is needed for the parent directory, one for the candidate (it must load an entry to test if it matches). Then it returns the found entry, so at least 3 are needed to perform the search. But it's just theory.

[AScha.3]

well , i am a newbie with this rtos - so i am just in a try and error state . 

but > Holly cow, I'm surprised it works wit so little stack for your file access thread

maybe is more about the settings for "allowed space" to use : the "..NB_BIT.." settings. compare yours to mine.

+ in filex thread i just open (mount) and check ok or not ; and show free space on card , here:

+ for find/open directory use:

btw

what i miss really, are some working examples (like in arduino world) to see how to do it .

Like searching in dir tree up and down and so on...

the "example" by STM is just useless , ( open file, write, read, close; in root dir. only ! ) and only this 

in all examples they have (or i found) . thats a mess.

[HTD]

Oh, my fault, I forgot the stack grows backwards. So my stack is basically empty. There must be another cause of the crash. I disabled the media statistics and reduced the caches. It didn't help. My tests pass on ExFAT volumes, but crash on FAT32 volumes.

[HTD]

I'm working on abstracting STM32 middlewares to a common C++ API. (Meaning it will be able to use both FILEX and FATFS as backend). It will end up Open Source, but first I have to make FILEX stop giving me Hard Faults on fetching a single directory entry 😉 The value added will be simplicity and RAII.

OK, it's finished and it works. It turned out my crashes were caused by 2 bugs in my code: 1) my own thread management issue, the file operations were called from USB HOST thread having minimal stack memory assigned (it should be redirected to the main thread with enough stack memory), 2) the `FX_DIR_ENTRY` structure must be properly initialized before calling internal `_fx` functions, I've checked the sources how they make it, I implemented identical initialization and it works. Why do I call internal functions? Because I have my own `DateTime` structures and I wanted to read the time stamps directly from the entry structure to do the conversion my way.

Now - it not only pass the basic tests, but it also passes the test when I read and write 2 devices at the same time. I start the I/O test both on SD card and USB disk. I reenabled the media statistics, I increased the cache sizes, now I just can't crash it.

BTW, here's my memory setup: