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​ 

[JBram.1]

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.

[JBram.1]

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.

[Tesla DeLorean]

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.

[Tesla DeLorean]

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

[Tesla DeLorean]

STM32H750

VBT6 V

7B377 VQ

PHL 7B 044

2020 Week 44 not working

[JBram.1]

Shouldn't that be AHB2 instead of APB2?