cancel
Showing results for 
Search instead for 
Did you mean: 

How to enable the STM32H750VBT6 HW crypto?

JBram.1
Associate II

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?

1 ACCEPTED SOLUTION

Accepted Solutions
STOne-32
ST Employee

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.

View solution in original post

14 REPLIES 14

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

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..

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

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​ 

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..

To further debug this I tried the following:

  • Set RNGEN in AHB2ENR
  • Read the RNG_CR and confirm it has the documented reset value of 0x0000_0000
  • Set RNGEN in RNG_CR
  • Read back RNG_CR confirming that the register write took effect (0x0000_0004).
  • Read the RNG_SR (0x0000_0022). The RNG requires more configuration.

This short test is enough to confirm that AHB2 peripherals accessible as CRYPT, HASH and RNG are connected to AHB2.

I also followed the steps described in https://community.st.com/t5/stm32-mcus-security/stm32h750vbt6-access-crypt-registers-all-read-back-zero/m-p/204834 bei @pavel A.​.

  • Set HASHEN in AHB2ENR
  • Wait a few seconds (why?)
  • Zero HASH_CR (it no visible change from the reset value)
  • Set DATATYPE to 8 bit (0b10) in HASH_CR
  • Read back HASH_CR (still reads 0x0000_0000)
  • It should have stored the data type but didn't.

Shouldn't have to wait seconds, but a) there are write buffers that defer the action on the register, b) there's a secondary hazard where the clock enable needs to latch, and clock the peripheral for several cycles before touching it directly.

The macro's typically write and read back the register, this forces the write buffers to clear, but also forces in-order completion.

Why? ARM generally avoids wasting transistors protecting against pipeline, bus and cache-coherency corner conditions. Back-to-back writes will buffer and occur within a bus cycle of each other, and this can be overly tight when enabling clocks on slower peripherals, or that themselves have a deeper pipeline or state-machine.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..

I have a couple of parts here where Pavel's test passes

STM32H750

VBT6 V

7B738 VQ

PHL 7B 018

STM32H750

VBT6 V

7B736 VQ

PHL 7B 049

So 2020 Week 18 and 2020 Week 49 both look solid

Enabling the CRYP clock on APB2, SR == 3

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..

STM32H750

VBT6 V

7B377 VQ

PHL 7B 044

2020 Week 44 not working

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..

Shouldn't that be AHB2 instead of APB2?