How to enable the STM32H750VBT6 HW crypto?

[JBram.1]

I've tried to enable the CRYPT and HASH peripherals by setting bits 5 and 4 in the AHB2ENR register, but all peripheral registers read as zero and writes are ignored as if the clock wasn't enabled or the peripheral was missing. Does this chip have hardware crypto and if it does what's required to initialize the hardware to calculate a SHA256 hash?

[Tesla DeLorean]

Per my previous response in the other thread, I do recall some complaints about at least one batch of devices. You'll need to work with the ST FAE assigned to your account, or via your local sales rep/office to see if you can identify this as the issue for the parts you have.

I would suggests photographing, or reporting the markings on the chips in question, or the packaging/reels they came from, so perhaps as a user-forum we can narrow this down to a week or batch code?

https://community.st.com/s/question/0D53W000005rNVJSA2/we-are-using-stm32h750vb-for-this-please-send-me-crypto-aes-128bit-code-examples-in-online-we-got-lot-of-crypto-lib-but-we-need-example-source-code-for-this-crypto-aes128-bit

[JBram.1]

Here is a picture of the chip. If I'm decoding the date code correctly the chip is from 2030 calendar week 39.

I'm not sure about some characters (mostly B vs 8) given the image quality and font, but these are the four lines of markings on package:

1. STM32H750
2. VBT6 V
3. 7B469 VQ
4. PHL 7B 039

[Tesla DeLorean]

Seems consistent with the spate of reports from the first half of the year

https://community.st.com/t5/stm32-mcus-security/stm32h750vbt6-access-crypt-registers-all-read-back-zero/m-p/204834

@Imen DAHMEN​  @stone-32​ 

[STOne-32]

Dear @JBram.1​  @Community member​ ,

I confirm that we had in second half of 2020 a test program issue at our factories, during manufacturing, leading to cryptographic feature disabled (CRYP and HASH). In case these cryptographic features would be used in final application, functionality failure will be visible immediately (100% failure rate) as you have seen with 0x000..

We sent a Quality Alert to all of our customers/distributors at that time by December 2020 and then Issue is fixed at our Factories, To be very specific not all parts are impacted by few Lots at specific factory where date code is from 2020 Week 22 to 2020 Week 47 . 022 to 047 may be impacted.

In case customer application would require these specific cryptographic features and to avoid any customer manufacturing burden, ST recommends recalling all unused impacted material and will issue a return material acceptance (RMA) accordingly, so please to go in touch with your local distributor or ST sales Offices. Our customers not using theses features, they will not see such impact.

Hope it is more clear now.

Ciao,

STOne-32.

[JBram.1]

Thx for admitting your colossal screw up. I have lost at least three weeks debugging this because my code did follow the reference manual. Please update the errata sheet to help the next poor fellow loose less time to this issue.

[Tesla DeLorean]

Cross linking this so I can find it later, also out of Amkor ATP

https://community.st.com/s/question/0D53W00001pvCJQSA2/how-to-detect-stm32f437-vs-stm32f427-via-software-am-i-victim-of-chip-fraud

[Tesla DeLorean]

Back linking to this thread, so I can cross reference later, and so Google / Bing / ChatWTF can spider.

https://community.st.com/t5/stm32-mcus-security/aes-ecb-initialization-fails/td-p/614297