[dgarske]

The SWTPM UART transport configures the TTY with VMIN=0, VTIME=200, so read() returns 0 after 20 seconds with no data. SwTpmReceive() treated that zero-byte read as EOF and failed with TPM_RC_FAILURE. Any TPM command that took longer than one VTIME period failed on the host even though the device completed it and WOLFTPM_SWTPM_UART_RX_TIMEOUT_SECS allowed longer.

RSA-2048 primary key generation on an MCU fwTPM can take that long. Because a primary key is derived from the NV seed, a given board then failed the same command every time.

Fix

• SwTpmReceive() - on the UART path a zero-byte read keeps waiting until the cumulative timeout instead of returning EOF; socket transports are unchanged.
• WOLFTPM_SWTPM_UART_RX_TIMEOUT_SECS default raised from 30 to 60 seconds; it remains overridable.

The cumulative timeout still applies per receive call, as before.

Testing

• Validated on a NUCLEO-H563ZI running the wolftpm-examples STM32H5 fwTPM over the ST-LINK VCP: wrap/wrap_test passes with an RSA primary that takes longer than one VTIME period, and caps and examples/pqc pass.
• configure sweep including --enable-swtpm=uart and the socket swtpm builds.