2022-09-29 07:04 AM
Hi,
I have a chip marked as STM32F437 but my software fails on running the SHA256 algorithm on the hardware crypto module.
The only difference to the STM32F427 is the additional presence of a hardware crypto accelerator in the STM32F437.
How can I check that the crypto module is present and enabled?
When I check the DBGMCU_IDCODE register I read 20016419h on both.
That means
-DEV_ID: 2001h STM32F42/STM32F43 Rev 3,4,5, and B.
-REV_ID: 419h STM32F42 STM32F43
So I can not differentiate between STM32F42 and STM32F43.
How can I do that?
Is there any known criminal chip cloning known for STM32F437?
I attach pictures of the chip that works as expected and a chip that dos not work.
Thanks in advance, Adib.
--
2022-09-29 07:30 AM
You could try to access the CRYP registers from base address 0x5006 0000 or the HASH registers from 0x5006 0400, which should trigger an error on the STM32F429.
Regards
/Peter
2022-09-29 08:47 AM
Hello Peter, thanks for your fast response. I use the HASH module for SHA456 calculation.
On the good one I read before calculation CR:0020, SR:0001 and after calculation: CR:400A0, SR:0003.
where on the bad module I always read 0000h.
Also my Keil Debugger reads only Zeroes for this peripheral. The corresponding AHB2 Clock enable bit is set correctly.
There is no such thing like BUS error. nor calling Error_Handler() from the HAL functions.
The project was created from CubeMX 6.2.1 and STM libs 1.26.1. I will update to CubeMx 6.6.1 and libs 1.27.1 .
Stay tuned ...
Adib.
--
2022-09-29 09:02 AM
no, it does not work differently with most recent libraries. :(
HASH module seems non existent on this chip.
Is there any other dependency for the HASH module to work?
regards, Adib.
--
2022-09-29 09:30 AM
My recollection is that the PLL / Q needs to be providing ~48 MHz, ie running, same for SDIO
You might be able to see the HASH/CRYP clock enables stuck-at-zero, or the peripheral shows all zeros.
I also strongly recollect there being a batch or weeks spanning window where the HASH/CRYP were fused off on STM32 die in test/programming, likely F4's
@Peter BENSCH @Amel NASRI can you double check the 2018 Week 27 logs
2022-09-29 09:39 AM
Hi Peter, could you please check the chip marking for the bad chip.?
it displays in the revision position a "2" where the good chip displays "3".
In the errata sheet ES0206 there is no such revision "2" listed for STM32F427/437 ???
Only revisions "A", "Y", "1" and "3" are listed.
Also the reported revision from Chip DBGMCU_IDCODE register "2001" does not relate to the labeled "2" on the device picture. This must be a "3".
No?
Many thanks for feedback, Adib.
--
2022-09-29 10:00 AM
Hello Tesla DeLorean, thanks for your response.
2018 week 27 is fine. I have problems on the other year 1 week 33.
This one reports revision "2". I checked our old PCBs. We have Revision "3" back to 2016.
As the code is same on the boards I would expect behave the same.
The Errata reports that after setting RCC clock enable one has to wait. I implemented some DSBs, NOPs as ewll as dummy reads with no luck.
Was there such revision "2" ?
Regards, Adib.
--
2022-09-29 10:53 AM
Sorry, didn't see the titles
The 2 and 3 in these positions are line codes, not chip steppings
2022-09-29 11:46 AM
Well, I'm sorry, but in this case I can't help for once. At least I haven't come across a rev 2 for the STM32F427 yet. The photo of the 2 version is unfortunately blurred, a comparably sharp picture like the other would make it easier to e.g. assess the fonts.
However, your supplier should be able to guarantee clean traceability, if he is a trustworthy one. Or have you resorted to broker goods in your time of need?
Regards
/Peter
2022-09-29 01:00 PM
This was one of the cases:
https://community.st.com/s/question/0D53W000010RpinSAC/how-to-enable-the-stm32h750vbt6-hw-crypto
@STOne-32 can you check 2021 Week 33, Amkor ATP (Philippines), STM32F437VGT6, Thanks