HardFault in Function CRC_Lock

[jimmii]

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.

[jimmii]

No it's not readable. Everything is 0.

[waclawek.jan]

@Martin KJELDSEN​ 

> What goes wrong here is actually that the Device ID of the Chip is not read properly with a Keil project (in debug mode using some particular version of ST-Link,) and thus the lock defaults to checking a CRC on the wrong address.

 >

> Probably related to DBGMCU not being readable at all.

Thanks for the info.

Oh, that's interesting. And annoying. And indicates undocumented features which are being used by that STLink. I hate when semi companies play the hide-and-let-the-user-guess game.

RM indicates that DBGMCU is mapped at two addresses - at the critical moment, is it unreadable at the other adress, too?

Jan

[jimmii]

It's unreadable at both adresses.

/jimmii

[Martin KJELDSEN]

Yeah, that's the problem. This is where the device ID is located which is then used to determine which address to use for the CRC.

As @ECiav​ mentioned, he's using Keil 5.29 and stlink v3 firmware which seems to have fixed the issue in debug mode for Keil.

/Martin

[Martin KJELDSEN]

@Community member​, very annoying indeed. I'll try to do some more tests here when i can re: combination of Keil/st-link firmware. And we'll get some feedback from @Roman Schläpfer​ if he contacts Keil.

/Martin

[jimmii]

Yes, very annoying.

I opened a ticket with Keil, but didn't hear anythin yet. Keep you updated.

[waclawek.jan]

So I think we cannot help more here.

/jimmii, your options are to change the STLink and Keil version as outlined above, and/or pester ST directly again.

@Martin KJELDSEN​ , your team probably should consider a fail-safe fallback for a case when the DBGMCU is not available, not trying to read the CRC register if you're unsure where it is, and if it's seen as a security flaw then limit functionality and provide an error printout or whatever.

ST @Amel NASRI​  , this definitively should go to the errata, rather than just been waived away with "oh we fixed firmware in STLink3" (at least that fact should go to the errata).

Does it affect other ST models, or just the H7; and does it affect all H7?

Unaccessible DBGMCU means unaccessible registers which are needed to debug (the freeze registers), so it's kind of ironic that it happens with debug pod attached.

JW

[Martin KJELDSEN]

@Community member​, thanks for the suggestion; I'll consider if we should have some kind of fallback in the case of a missing device ID. Even in the rare case that some toolchain, in debug mode, does not map registers properly, it's not the easiest thing to figure out for a user.

We've just finished work on debug printers for all available LCD drivers with hand-written font glyphs for development that would come in handy here. Even if the device ID is evaluated OK but the CRC check fails we could write something like "Please activate CRC".

/Martin

[jimmii · Accepted solution]

So, after updating the ST Drivers and Keil uVision to the latest Version (couldn't do it earlier because of other projects), everything seems to work now.

Thank you all for the great support.

@Martin KJELDSEN​ keep up the good work!

If I get response from Keil, I will post it here.

[Martin KJELDSEN]

Glad to hear it worked out for you, @Roman Schläpfer​. Keil will probably just say it's fixed in the latest version and that they know they had a bug at some point, but let's see! 🙂

/Martin