Hard Fault on function start - but cannot debug

AScha.3 · ‎2023-12-07

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:

If you feel a post has answered your question, please click "Accept as Solution".

AScha.3 · ‎2023-12-13

Yes, seems working now . 8)

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. :grimacing_face:

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... :)

If you feel a post has answered your question, please click "Accept as Solution".

View solution in original post

waclawek.jan · ‎2023-12-07

Is the floating-point coprocessor enabled?

JW

HTD · ‎2023-12-07

I have similar experience with Hard Faults. In my case I just allocated a bigger memory pool for the component and it worked. So the library I used (FILEX) probably had a bug with some out of bounds writes. In a perfect world it should crash into a nice spin loop showing you exactly where it could not write data. And when you have the stack frame overwritten - no debugging for you. That's probably the kind of bug where the data goes where it should not go. The common symptom of this is debugging showing nothing or just some random garbage that makes no sense.

Tesla DeLorean · ‎2023-12-07

Looks like it might depend on the double precision FPU-D of the H7. Perhaps use library from CM4F part or F74x core with FPU-S

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..

AScha.3 · ‎2023-12-07

should be...

If you feel a post has answered your question, please click "Accept as Solution".

AScha.3 · ‎2023-12-07

...there was a problem with : on what cpu we are here ?

float seem used .

but at first the mp3-lib had some ARM64 setting found in defines...i dont know why.

i just put a "!" (=not) on this define, to get

#define HAVE_ARMV6 0

before it had aarch64 active. Crazy, this was not in my H743 project (but i dont remember, whether i set some define there or modified a global define...afaik i didnt; it was set right and worked. )

now armv6->0 and so should be ok, in this respect.

optimizer..on -> no errors + warnings

paths seem ok:

If you feel a post has answered your question, please click "Accept as Solution".

LCE · ‎2023-12-07

> ...there was a problem with : on what cpu we are here ?

Is it working now?

AScha.3 · ‎2023-12-07

no.

thats why i asked - i thought, now all should be ok. and no idea, what still wrong. :frowning_face:

If you feel a post has answered your question, please click "Accept as Solution".

AScha.3 · ‎2023-12-07

@HTD , right, i also had suspicions against Azure - stack, memory management - and increased values:

8K stack, 100K mem

but not in filex, because this seems (!!!) working fine.

still have 300K ram free, so i try with more mem for filex thread - as you suggest.

If you feel a post has answered your question, please click "Accept as Solution".

waclawek.jan · ‎2023-12-08

As @Tesla DeLorean said above, from disasm (vpush of double registers) it appears that the library uses double-precision FPU which is not available in Cortex M33/'H5. I'm not versed enough to tell if vpush of double is indeed dependent on presence of the double-precision FPU, but, just another question to the many: do you compile that library from sources, or does it come as a precompiled .a?

Also, I'm not sure the -fpu setting guarantees the FPU to be switched on. IIRC in the Cube infrastructure, compilation of the couple of instruction needed to switch it on depends on some specific preprocessor symbols to be present - see startup code or functions called from there for relevant details.

JW