Stuck in TPM2_Startup(&startupIn) function

[lyw0901]

hardware environment: STM32F4297 + TPM module issues: before sending a TPM2_Startup cmd to TPM, there is a function named TPM2_TIS_WaitForStatus(ctx,TPM_STS_COMMAND_READY,TPM_STS_COMMAND_READY) to check the TPM chip whether ready to receive this command or not, but the status returned in TPM_RC_Status() is always 0x00 but not 0x40(TPM_STS_COMMAND_READY), so the procedure is stuck in TPM2_TIS_WaitForStatus() function. The command&response stream in SPI channel captured with logic analyzer tool is as bellow:

80D40000 <<00000001A0 80D40000 <<00000001A0 83D40014 <<0000000197060030 83D40F00 <<00000001D1151D00 80D40F04 <<0000000126 80D40018 <<0000000100 00D4001840 <<00000001C0 80D40018 <<0000000100 80D40018 <<0000000100 80D40018 <<0000000100 ... Can you help me find out what's wrong？

[lyw0901]

the TPM module chip is Ifineon OPTIGA™ TPM SLB 9672

[dgarske]

Hi @lyw0901 ,

The TPM startup and self test can take a decent amount of time to complete. Have you tried waiting longer? Attached is the output from running our examples/wrap/wrap_test with --enable-debug=io set using the SLB9672 for comparison. I added "..." in the repeating section. For me on the Pi I used /dev/spidev0.1 at 33 MHz.

wolfTPMRawTIS.txt

Thanks, David Garske, wolfSSL

[lyw0901]

hi David Garske, After the device power-on, I added a delay of 5s to start the initialization，does waiting you mentioned above refer to this? And is it enough? The SPI boundrate i used is 33MHz too. I compile the project with STM32CubeMX, and burn the project to STM32F429 chip with JTag.I compared my log with your .txt attachment, for command 80 d4 00 18 00, my response is 00 00 00 01 00, yours is 00 00 00 01 40, and then my next one is to write the command 00 d4 00 18 40 to device, the response is 00 00 00 01 c0, it seems to write fail, is c0 a status code? And what does it mean? Thank you very much! Yawen

[dgarske]

Hi @lyw0901 (Yawen) ,

Are you using our STM32 HAL driver or one you wrote? Make sure you are using mode 0. Have you tried slowing your SPI bus? Is anything else on the SPI bus? Have you power cycled the TPM to make sure it is in a good state?

Thanks, David Garske, wolfSSL

[lyw0901]

hi David Garske, yeah, we are using your STM32 HAL driver, and using mode 0. We have tried to configure the SPI boundrate to 1MHz. The issue is the same. There is other data interaction on the SPI bus, and the data interaction on the SPI bus before ”80 d4 00 18 00 “is the same as the data interaction in your .txt attachment，but our response to this command is" 00 00 00 01 00" and yours is "00 00 00 01 40“, then there is a command "00 d4 00 18 00" on our side , the response is ”00 00 00 01 c0“，we don't know what the c0 in the response means. Before wolfTPM2_Init(), we did a Warm Reset by referring to the SLB9672 data sheet, the reset pin RST# was repeatedly pulled down and up three times, each time for 1s.

[dgarske]

Hi Yawen,

Can you share the build settings for wolfTPM you are using (the ./configure or user_settings.h)? Have you tried using ./configure --enable-infineon=9672 like I used in the log attached? This defines WOLFTPM_SLB9672.

I have both STM32F4297 and Infineon SLB9672 HW here, so if you can share your project I am happy to review and try out. Feel free to take this to a private thread by emailing support at wolfssl.com directly.

What firmware version is running on your SLB9672? Typically the Infineon chips don't require a SPI wait state, but you might consider enabling WOLFTPM_CHECK_WAIT_STATE to see if that helps.

We do have an STM32Cube wolfTPM pack here https://www.wolfssl.com/files/ide/I-CUBE-wolfTPM.pack. Feel free to check it out and let us know if you have any feedback. Find the docs to get started here https://github.com/wolfSSL/wolfTPM/blob/master/IDE/STM32CUBE/README.md

Thanks, David Garske, wolfSSL

[lyw0901]

hi David Garske, Thank you so much for your replies! We have tried all the methods you mentioned above, but the issue still exists, we have no idea. The project we used was generated by the pack that you mentioned above. Since the emails I sent to you were always reported as spams, I uploaded the project to here: https://github.com/lyw0901/wolfSSL-wolfTPM-issue-295-Replication, please unzip it first as it's compressed in 7z format. The path of the project file is OPENSTM32\MDK-ARM\wolfSTM32.uvprojx, the entrypoint is OPENSTM32\Src\main.c. Thanks again! yawen

[lyw0901]

hi David Garske, Sorry to bother, is there any progress？ Thank you! yawen

[dgarske]

Hi @lyw0901 ,

My contacts at Infineon said to reach out to them. They have some ideas for how to solve this. Do you have an FAE contact at Infineon?

Thanks, David Garske, wolfSSL

[lyw0901]

hi David Garske, We replaced the Infineon SLB9672 chip with the Infineon SLB9670 chip, now the communication is normal. Thank you very much for your help! If there are any other questions, we'll ask you！ Thanks again!

[dgarske]

Hi @lyw0901 ,

On the SLB9672 make sure you hold it in reset until the power rail is fully up. If that doesn't help let me know.

Thanks, David Garske, wolfSSL