Orin NX SPI Clock Stops During TPM SPI Communication

Robotics & Edge Computing Jetson & Embedded Systems Jetson Orin NX
, ,
1

Hi,
We use an Orin NX with JP6.1 on a custom carrier board.
We try to use the “tpm_tis_spi” in-tree kernel driver to communicate with a TPM 2.0 SPI device -ST33TPHF20SPI

The communication fails and the driver prints a timeout error:

tpm_tis_spi: probe of spi0.0 failed with error -110

We used a probe to examine the protocol and noticed the following issue:
We see that Orin NX halts the clock after Command and address phase, therefore TPM device doesn’t release the expected data.

protocol:

image
image690×419 87.1 KB

image
image1001×865 208 KB

Why the Orin NX halts the clock, not allowing the TPM device to respond?

Thanks

3

Hi bsp_dev,

Could you reproduce the similar behavior on the devkit?

What’s the level for your signal? I can not get voltage info from your image.
Could you also measure CS pin to check if it is still asserted (pulled low) when the SCK is halted?

4
  1. Regarding devkit - we don’t have a tpm on the devkit.
  2. signal level is 3.3V
  3. CS is asserted (‘0’) while clock is halted
5

If it is okay at your side, please rework one tpm to verify on the devkit.

Could you try to apply the following patch to check if it could help in your case?
Jetson orin nano SPI Speed not changing - #9 by KevinFFF

7

Hi,
We have some improvements after applying this patch: we finally got an ACK from the TPM device on the 5th byte!
After that, the Orin NX put 4 extra empty bytes on the bus to read the data from the TPM.
But unfortunately, it also toggled the CS pin between that, so the transaction was aborted and the TPM did not send the data back to the NX (because when CS goes high, the TPM closes the current transaction).

See attached scope screenshots of this transaction.

Tek001_000
Tek001_0001755×1049 90 KB

Tek001_001
Tek001_0011920×1080 174 KB

Tek001_003
Tek001_0031920×1080 160 KB

8

Could you point out where’re these 4 bytes from MOSI in your waveform?
The current waveform looks good to me that the CS disserted after transaction finished and it asserted again before the next CLK signal.

9

Hi,
MOSI is the red-colored waveform (also the first waveform of the SPI analyzer, at the bottom of the screenshot).
These empty bytes are better seen in the zoomed (3rd) image (I’m posting it again below). The driver put 4 empty bytes (6-9th) on bus to push the data out of the TPM. But since CS* de-asserted before this, the TPM resets the previous transaction and now expects to a new one with the ID, header etc…

Tek001_003
Tek001_0031754×1049 106 KB

10

There is no update from you for a period, assuming this is not an issue anymore.
Hence, we are closing this topic. If need further support, please open a new one.
Thanks

Have you confirmed that there’s valid data you sent from MOSI rather than 0x0?
If so, please share the detailed steps how did you reproduce it for us to verify it locally.

How do you confirm that there’s the data not 0x0 after 6-9th bytes?

I’ve also noticed that you are using 1.8V for SPI interface.
Have you checked if your TPM module is also working with 1.8V? Or it should be 3.3V?