SDMMC with STM32H7

[paulca]

I got an H743 board from MCUDev via AliExpress.

I created a base IOC file for it, so I don't have to check the external peripheral connections for every project, I can just disable the ones I don't need for that project.

I set up the 4 bit wide SD card slot using SDMMC1 with the correct pin out.  However it seems as though the HAL_Init function for the SD card slot requires there is an SD card in it and if there isn't it goes Hard Fault.

Is this expected?  It seems to fail in and around doing the voltage drop sense if it's an MMC card or a V2.0 SSD card.  It seems to determine it's  V2.0 SSD Card (it's actually empty), then tried some test command on it and times out.

Next to test the 8Mb of quad spi flash.

Of no particular interest.  38us is how long it takes to mix 1 milisecond of 2 audio buffers.  Nice.  Need to test how long it takes to run a 5 band EQ on the resulting buffer next... week.

[DavidAlfa]

This is the 10^173 time you post something without any code, do you really expect any help this way?

Whenever you get a hardfault, check where it was generated, the debugging panel shows the last few calls, and usually the variables hold their values at the moment of the crash.
So just don't sit there, " Meh, I got a Hardfault", it's probably caused by a null pointer because something failed to init properly.
In any case, you should be able to see the exact line where it crashed.

I've tried HAL SDMMC in the past, worked well.
Maybe you're skipping some checks, like the return statuses, you can't simply do this:

Code: [Select]

void init()
{
    HAL_SD_Init();
    Do_Something();
}

Instead, always check the returning value was 0 (HAL_OK).
Making you own error handler which is simple, and a little macro will make it even easier.

Code: [Select]


#define test(func)    if(func) handle_err(__FILE__, __LINE__)

void handle_err(char *file, int line)
{
    printf("Error in %s:%d\n", file, line);
    while(1);
}

void init()
{
    test( HAL_SD_Init() );
    Do_Something();
}

Simple example: https://onlinegdb.com/-zODV20KQ

Also remember to always check the stack usage and adjust it in MX.

HAL code using USB / Storage / Filesystems (also *printf) functions use heap allocation, so try increasing it to something large like 8KB-16KB.
After this, initialize everything, call all HAL and std functions (Including printf, etc) to make sure all the buffers were allocated, then check the heap usage with mallinfo().
The value you need is uordblks (Allocated heap in bytes), adjust the reserved heap accordingly with some little extra, you don't want to waste memory either.

[paulca]

I didn't post code because I basically just clicked the boxes, compiled the generated stuff and it hardfaulted in the init function.

I mentioned details which I gleened from stepping through the HAL code which revealed that most initial tests pass, but it fails on a test function ( can post next time I'm in that project ) with a timeout setting in the registers.

I have many other issues after that establishing coms with the hardware.  Too many variables in how it's setup, researching it from datasheets will take a while.  Someone out there has done this and already knows the answers, that's why I asked.

It seems to annoy you, that I have a practice to ask first, follow up later.  I'm a software engineer.  Human communications are slow, so they are best launching in parallel to further self analysis and research.  I'm used to a world where if you think something is broken beyond your control it best to establish and confirm that as fast as possible.  If you need human to human communications to establish that, best get them started NOW.  It's easier to say, "It's okay, I worked it out" after a day than try and justify sitting on your arse and procrastinating with a problem rather than reaching out and asking.  Nothing pisses me off more than to hear a junior engineer has sat with the same problem with no movement for 3 days.

Your not alone in it annoying you, I even had a word with a manager on that point once before.  However he ended up losing the debate and accepting I was right based on team intercommunications and team shared knowledge making things go faster.  An unanswered question costs and infinite amount of time.  If another team member can answer that question it saves an infinite amount of time.   There are limits of course.  Asking the same question multilpe times, even in different ways/contexts is annoying.

Your not in my team and you don't need to care, but you do, which is nice.   I will try and delay my posts somewhat until I have a more complete set of information.

If I'm honest I probably write about 10 times more these messages as I send, because more often than not (10:1) I answer my own question simply throught he act of asking the question correctly.

In this case I was moving pretty quickly and wanted to drop the SD card interface and move on to others which didn't go well either!  I spared you those posts.

[DavidAlfa]

- My car is doing some weird noises! Please help!
- What noise?
- Doesn't matter! Only a noise. Not posting any recording, so the solution goes faster.
- 

- Doctor, I feel pain!
- Where do you feel it?
- Doesn't matter, just fix it so it stops hurting faster!
- 

You're doing the same! 

I don't agree at all, I have a very simple rule, no code - no help!
Always show something, at least the SD initializing code, which is usually only few HAL lines!
You could be doing 1738 things wrong, a Hardfault is a very generic error.

"I just stepped somewhere inside the HAL code and then it crashed"
Ah! I got the solution then! There's a problem somewhere in the code, just fix it!

Not anoyance at all, it's an advice, you'll be hardly getting any help doing that.
No faster, but slower!