2019-12-03 06:57 AM
Hi,
I'm using the STM32H750 Discoveryboard.
When running my code from TouchGFX Designer, everything works fine.
But when running with Keil IDE, something strange is happening:
-Flashing the application and loading with the debugger -> hard fault occurs in funtion crc_lock
If I unplug and replug the board, the application starts just fine. Only when connected to the debugger, the hard fault occurs.
Do you have any hints?
__HAL_RCC_CRC_CLK_ENABLE is being called, so that shouldn't be a problem
Thanks.
Solved! Go to Solution.
2019-12-05 02:23 AM
Okay, let me know how you do - I'm pretty interested in whether or not this is an issue everyone will be having.
Thanks!
/Martin
2019-12-05 02:24 AM
Sure, will update this thread with the findings...
2019-12-05 02:40 AM
Thank you!
2019-12-05 03:58 AM
So, after you single-step from that line, you get the hardfault?
It's an attempt to read from an undefined address, 0x40023008. I'd say, this binary is not intended for the 'H750, you've maybe linked some incorrect library.
Show us the mixed source/disasm view, or use any other means to locate that binary to its respective source line.
@Martin KJELDSEN ,
What's that CRC_Lock() function, is it part of your software? If yes, do you provide it as a binary library?
JW
2019-12-05 04:10 AM
Yes, exactly. After single-stepping I get the fault.
I don't have a source line, because the CRC_Lock() function is located in the TouchGFX library.
And I don't know if it's the correct one, but I hope so, since it's tho only one I got from TouchGFX.
I can't imagine, that this is a library issue, since the program runs just fine when I'm not debugging.
jimmii
2019-12-05 04:22 AM
@Community member Yep, it's a CRC lock that ensures you can only run TouchGFX on STM32 micros. This issue has something to do with Keil - Jimmii is going to contact them about it. They resolved the issue for a previous customer by sending him some new libraries and I was kind of hoping they'd fixed whatever the problem was.
I'd forgotten about it since i haven't heard from anyone else about this issue in over a year.
That being said, i think i'll do some digging myself into this.
/Martin
2019-12-05 05:24 AM
0x40023008 is CRC->CR for the 'F4, but not on 'F7 nor 'H7 (at least not at the few models I've checked).
This should be easy to debug on your side.
JW
2019-12-05 05:42 AM
I solve using the last Keil version (5.29) and the last stlink v3 firmware version
2019-12-05 05:49 AM
Another issue for keil is bad address for CRC->INIT and CRC->POL in the "Peripheral->System Viewer->CRC Tab window"
2019-12-05 05:52 AM
That's right, for the H7 it should be in the rage of 0x58024C00.
@Martin KJELDSEN could it be possible, that the library from the examples are wrong for the F7/H7?
How can I check if it's the right version?
jimmii