Showing results for 
Search instead for 
Did you mean: 

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

Associate II


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:

spi2 hal config.PNG

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

spi2_st33tp all traffic expected.png

Zoom in to first 2 bytes (correct behavior):

spi2_st33tp first 2 bytes of 1st transaction.png

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

spi2_st33tp first byte of second transaction.png

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:

spi2 at first 4byte trx req.PNG

Second time:

spi2 at second 4byte trx req.PNG

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?














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.


If you feel a post has answered your question, please click "Accept as Solution".
Associate II


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 🙂

spi_st33tp trx cont0.png




Associate II

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?