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]

@waclawek.jan  , ok, so i just set it to "software fpu " --- but still same: not even one step in the function possible.

+ give filex more space, 20K -> 120K ...but changes nothing.

+ i forgot to tell: at first i had it on a F411 (black pill) board, runs without problems. Just slower and not enough ram, to use other decoder (for FLAC) also, so i moved it to a H743 board, all decoders working here fine. 

But to get an audio host - big problem. No example by STM , just one USB audio-host, for a disco-xxx board. But i tried to use this, got it working...and then found: hey, it just can enumerate a headset ! nothing else !!

Just good for advertising : Oh, we have audio-host also !

so i looked for a REAL audio-host, but found only one , that looked promising: USBX - but is part of  Azure rtos.

So took new nucleo-H563 board, can import Azure, usbx, filex... and got it working, 

can enumerate a sound card and play on it.  good, so far. now add the decoders...flac seem ok, but mp3 makes this crazy hard fault. 

[LCE]

The above assembler, starting with STMDB and using the stack pointer, that's where it instantly fails?

I guess you already checked stack size and location in the linker file? Especially after increasing stack and heap?

[AScha.3]

>I guess you already checked stack size and location in the linker file? 

no - to be honest, i never ever looked at a linker file (what should i look for there?)

Just i think, i see it in debug anyway, at runtime (or not ??)

here (now) at decoder start:

thread info:

cpu:

I am at a loss . looks all ok for me...

UNTIL THE NEXT STEP ! then hard fault - not even in assembler one step to the function...

[AScha.3]

just a funny idea : can i jump to other position in this function?

ok, i moved cursor down 3 lines and set (menu)run -> move to line , then single step ... no problem !

so the problem is the first instruction - right? 

from ARM ...:  >>

STMDB / STMFD

Store Multiple Decrement Before (Store Multiple Full Descending) stores multiple registers to sequential memory locations using an address from a base register. The sequential memory locations end just below this address, and the address of the first of those locations can optionally be written back to the base register.

<<

how can this generate a hard fault, if SP is middle in the "byte pool" ???

[Piranha]

Tesla and Jan already told you that the VPUSH instruction is pushing double floating point registers and therefore the code is compiled for double sized FPU devices. Jan also asked whether you are compiling that module yourself or using an already compiled library.

[AScha.3]

sorry, i forgot to write: compile from source.

compiler setting should be ok:

and vpush - can be with single or double floats , as i read this:

<sreglist>

Is the list of consecutively numbered 32-bit SIMD&FP registers to be transferred. The first register in the list is encoded in "Vd:D", and "imm8" is set to the number of registers in the list. The list must contain at least one register.

<dreglist>

Is the list of consecutively numbered 64-bit SIMD&FP registers to be transferred. The first register in the list is encoded in "D:Vd", and "imm8" is set to twice the number of registers in the list. The list must contain at least one register, and must not contain more than 16 registers.

but : i tried -as i wrote- also with software float - but same : hard fault at stmdb instruction.

here is the code for this function:

int mp3dec_decode_frame(mp3dec_t *dec, const uint8_t *mp3, int mp3_bytes, mp3d_sample_t *pcm, mp3dec_frame_info_t *info)
{	// inp.buf. >   ; decodiert 1 frame ca. 418 B./128kb = 1152 sampels = 4608 Byte
    int i = 0, igr, frame_size = 0, success = 1;
    const uint8_t *hdr;
    bs_t bs_frame[1];
    mp3dec_scratch_t scratch;

    if (mp3_bytes > 4 && dec->header[0] == 0xff && hdr_compare(dec->header, mp3))
    {
        frame_size = hdr_frame_bytes(mp3, dec->free_format_bytes) + hdr_padding(mp3);
        if (frame_size != mp3_bytes && (frame_size + HDR_SIZE > mp3_bytes || !hdr_compare(mp3, mp3 + frame_size)))
        {
            frame_size = 0;
        }
    }
    if (!frame_size)
    {
        memset(dec, 0, sizeof(mp3dec_t));
        i = mp3d_find_frame(mp3, mp3_bytes, &dec->free_format_bytes, &frame_size);
        if (!frame_size || i + frame_size > mp3_bytes)
        {
            info->frame_bytes = i;
            return 0;
        }
    }

[waclawek.jan]

@Piranha,

In this post above @AScha.3 showed non-FPU version of the code which fails too; so the problem is probably not the FPU.

(I'm also not sure whether VPUSH of double registers is not implemented also in SP FPU, but that's another discussion).

This processor is Cortex M33, i.e. "secure"; can't the issue be related somehow? I know nothing about it as I hate reading ARM's litanies, but can't e.g. a piece of code be forbidden from accessing some RAM area, e.g. the place where stack is?

Aren't there more fault-related registers containing more details?

JW

[AScha.3]

Jan, about "secure" (i hated also, to even read about it) i tried to avoid anything to activate. But ...who knows.

+

because end of my logic...i just tried to change the code by using no optimizer (-O)

and surprise: the mp3decode() is no more reached, hard fault before/or at jumping :

this is last position, next step -> hard fault.

and here , where he should go : to mp3decode , now without any vpush . :)

but same fpu in hardware setting.

[HTD]

I'm not sure if I haven't got lost here, but is this that FILEX related thing? Because if you run in on M33, I run it on M33 too. STM32U599 to be specific. I tested it with several SD cards and several pendrives. Do you use version 6.2.0 of FILEX? You will find the version in `fx_api.h`. I tested it with 6.2.0.

[AScha.3]

@HTD , yes is 6.2.0  too. 

seems to work fine now. (with short wires to sd-card-holder).

see -if you want -

https://community.st.com/t5/stm32cubeide-mcus/sd-card-not-working-with-azure-filex-anybody-got-it-working/m-p/617597#M22578

the problem here ... is difficult. Maybe the compiler/toolchain is the problem.