The SR->TXTF flag automatically sets to "1" before all data specified in CR2->TSIZE has been transmitted.

[kl-dev]

1. After a few bytes have been transmitted, the TXTF flag becomes '1', even though CTSIZE has not yet returned to 0.
2. For now, I’ve implemented a temporary fix by setting the TXPIE flag to '1' each time TXTF becomes '1'.
3. It is worth noting that the first transmission of 70,000 bytes runs normally, but from the second transmission onwards, this error occurs.
4. I am following the instructions in sections 50.4.9, 50.4.10, 50.4.11, and 50.4.12.
5. I am using an STM32H743IIT6 chip.

Document page 2227 of STM32H742, STM32H743/753 and STM32H750 Value line advanced Arm®-based 32-bit MCUs - Reference manual

TXTF: transmission transfer filled 0: upload of TxFIFO is on-going or not started 1: TxFIFO upload is finished TXTF is set by hardware as soon as all of the data packets in a transfer have been submitted for transmission by application software or DMA, that is when TSIZE number of data have been pushed into the TxFIFO. This bit is cleared by software write 1 to TXTFC bit at SPI_IFCR TXTF flag triggers an interrupt if TXTFIE bit is set. TXTF setting clears the TXIE and DXPIE masks so to off-load application software from calculating when to disable TXP and DXP interrupts.

[TDK]

TXTF indicates that TSIZE number of data have been sent to the FIFO. It does not indicate that the data has been transmitted.

If you are looking for an indication of when the transfer is complete, use TXC.

[kl-dev]

Your answer contradicts the documentation, which states: "TXTF is set by hardware as soon as all of the data packets in a transfer have been submitted for transmission by application software or DMA—that is, when the amount of data specified by TSIZE has been pushed into the TxFIFO." Does this mean the documentation is incorrect?

 

And in contrast to my first run—where the initial transmission of 70,000 bytes functioned exactly as described in the documentation—all issues regarding the TXTF bits began to appear from the second transmission onwards.

 

During the first transmission, all 70,000 bytes are sent; only then does the TXTF flag switch to '1', indicating that the entire TSIZE amount has been transferred to the FIFO.

 

[TDK]

You are missing the distinction between bytes sent to the TXFIFO waiting to be sent out and bytes actually being sent out. There is a delay between the two. My answer is the same as the documentation.

TXTF happens, then after all bytes in the TXFIFO are actually sent, TXC happens. This is what you are reporting, and what the documentation is saying. There is no contradiction anywhere.

> The SR->TXTF flag automatically sets to "1" before all data specified in CR2->TSIZE has been transmitted

Yes, that is exactly how it is supposed to behave.

[kl-dev]

I understand your point, but the core issue I’m facing is this: the SPI interface transmits a few bytes (which I’ve verified using a logic analyzer), and the TXTF flag switches to '1'. However, I am attempting to transmit a total of 70,000 bytes, while the SPI peripheral only has a 16-byte FIFO (according to the documentation). If the entire TSIZE amount has already been transferred into the FIFO (indicated by TXTF = '1'), where is the rest of the data going—given that I’m sending 70,000 bytes in total? Notably, this issue did not occur during the first 70,000-byte transmission.