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]

Sure, will update this thread with the findings...

[Martin KJELDSEN]

Thank you!

[waclawek.jan]

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

[jimmii]

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

[ECiav]

I solve using the last Keil version (5.29) and the last stlink v3 firmware version

[ECiav]

Another issue for keil is bad address for CRC->INIT and CRC->POL in the "Peripheral->System Viewer->CRC Tab window"

[Martin KJELDSEN]

Just to rule it out: Please make sure that the CRC is actually activated.

[jimmii]

Yes it is activated. Think wouldn't work at all if it's deactivated.

[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

[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

[Tesla DeLorean]

There is other code in the library that checks the chip stepping. For example the VOS or others.

Should perhaps catch the zero state.

​

Definitely seen the zero read issue in Keil over the years.​

[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]

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