2021-08-06 10:30 AM
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?
Solved! Go to Solution.
2021-08-10 04:25 AM
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.
2021-08-06 10:47 AM
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?
2021-08-06 11:16 AM
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:
2021-08-06
12:38 PM
- last edited on
2023-11-29
08:11 AM
by
Laurids_PETERSE
Seems consistent with the spate of reports from the first half of the year
2021-08-06 01:50 PM
To further debug this I tried the following:
This short test is enough to confirm that AHB2 peripherals accessible as CRYPT, HASH and RNG are connected to AHB2.
2021-08-06
03:11 PM
- last edited on
2023-11-29
08:14 AM
by
Laurids_PETERSE
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..
2021-08-06 03:40 PM
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.
2021-08-06 07:16 PM
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
2021-08-06 08:13 PM
STM32H750
VBT6 V
7B377 VQ
PHL 7B 044
2020 Week 44 not working
2021-08-09 02:46 AM
Shouldn't that be AHB2 instead of APB2?