cancel
Showing results for 
Search instead for 
Did you mean: 

Hard Fault on function start - but cannot debug

AScha.3
Principal III

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:

AScha3_0-1701984656178.png

disassm shows here:

AScha3_1-1701984719271.png

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

AScha3_2-1701984805304.png

and this seem ok:

AScha3_3-1701984845368.png

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

next step ...hard fault :

AScha3_4-1701984947201.png

cpu then:

AScha3_0-1701985234450.png

 

 

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

Accepted Solutions
AScha.3
Principal III

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... 🙂

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

View solution in original post

34 REPLIES 34

Is the floating-point coprocessor enabled?

JW

HTD
Senior III

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.

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

should be...

AScha3_0-1702017777792.png

 

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

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

float seem used .

AScha3_0-1702018109479.png

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

AScha3_1-1702018330536.png

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

AScha3_2-1702018937594.png

paths seem ok:

AScha3_3-1702019033352.png

 

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

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

Is it working now?

AScha.3
Principal III

no. 

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

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

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

8K stack, 100K mem

AScha3_0-1702020370326.png

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

AScha3_1-1702020470076.png

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".

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