On Nucleo board H743ZI, HAL in use, byte wise TRX setup,after few bytes sent, no TX anymore.

[Wojt]

Hello

I got weird problem. I tried to experiment with WolfSSL+WolfTPM+ST33TP available package and example. All setup I did is according to available git pages as well as youtube tutorial. The original example was tested by WolfSSL on F4xx MCU, I tried to carry over all configurations carefully to my H7 nucleo setup.

To the point - I see communication on SPI2 is initiated - first transaction is visible on the lines. There are 3 phases for transaction:

-4 bytes TX (80 D4 00 00) /RX

-polling for wait states - in my case just single byte is TX/RX but wait flag is not seen.

-confirmation byte.

Then, next transaction is initiated, its exactly the same like the first one. But just SINGLE BYTE is transmitted (0x80) and that's it, bus is silent. When debugging I see that for both transactions the same data is feeded to HAL_SPI_TransmitReceive().

I attach:

SPI2 setup:

 

Overall traffic until TRX is gone (red circles mark where same TRX of 4 bytes should be visible):

 

Zoom in to first 2 bytes (correct behavior):

Zoom in to second transaction (NOK, just first byte is sent):

I also include 2 screenshots with state of all SPI2 registers in the moment (breakpoint stop) before HAL_SPI_TransmitReceive() is loading SECOND byte to TXDR for first and second transaction to see the difference. It is just one flag: TXTF which is set on second transaction but not on the first one.

First time:

Second time:

I went through documentation of SPI burt have no clue. I test on both SPI3 and SPI6. The issue is happening purely at STM32H743 side, I see such behavior even if I disconnect ST33TP. 

I include also c code of transmission from wolfTPM package. SPI relevant conditional code is included. It is original file, I only changed IO Pin, where I hooked up /CS signal.

I suppose that the example is working fine for F4 platform, I have no opportunity to check this though yet. I guess SPI peripherals are not the same between F4 and H7, for example FIFO depth setting is not available.

Does anyone has a hint?

Greetings!

 

 

[TDK]

SPI peripherals are very different between the two, but HAL functions should still work the same.

Perhaps debug the code, look at parameters that are used when calling HAL_SPI_TransmitReceive. Likely on the last call you're only calling it with one byte. It's impossible to tell with the code you've shown--what would be more informative is the upstream code that calls TPM2_IoCb_STCubeMX_SPI. It's clearly able to send more than 1 byte at a time, as evidenced by the first call, so must be something else in the code that would explain the behavior.

[Wojt]

Update!

I followed observed difference in SPI transaction 1 and 2 -> TXTF flag. When I clear TXTF flag, see below in red, in HAL_SPI_TransmitReceive() function, then I unlock transmission to go on; it seems working fine, will check more tomorrow. It is ad hoc experiment, more checks needed but at least traffic continues...

And screenshot from the scope :)

 

[Wojt]

Hello again

It seems that such simple fix helped me to get rid of the problem reported above. Now I concentrate on funcitonality itself of the SW stack behind ST33TP.

Nevertheless, the issue with unhandled TXTF flag, while HAL_SPI_TransmitReceive() is executing, which is blocking further  transmission until clearance, is not the expected behavior of SPI driver. If so, shouldn't this issue be taken over by HAL supporting staff to deeper investigation and potential bug fixing?

Greetings

Wojt