Inaccuracy in the description of USB STM32F103

[Arlleex1]

Hello everyone.

I came across some inconsistencies in the documented description of the USB controller in the STM32F103 relative to the USB specification.
Initially, I was interested in what would happen if the host sent an OUT transaction with PID DATA0, the device successfully received it, switched to DATA1 and sent an ACK, but the host for some reason could not receive this ACK (noise on the line, etc.).
The USB specification clearly writes (section 8.6.4 Corrupted ACK Handshake):

"At the end of transaction i, there is a temporary loss of coherency between transmitter and receiver, as evidenced by the mismatch between their respective sequence bits. The receiver has received good data, but the transmitter does not know whether it has successfully sent data. On the next transaction, the transmitter will resend the previous data using the previous DATA0 PID. The receiver’s sequence bit and the data PID will not match, so the receiver knows that it has previously accepted this data. Consequently, it discards the incoming data packet and does not toggle its sequence bit. The receiver then issues ACK, which causes the transmitter to regard the retried transaction as successful. Receipt of ACK causes the transmitter to toggle its sequence bit. At the beginning of transaction i+1, the sequence bits have toggled and are again synchronized."

That is, in the described situation, when the host sent DATA0, the receiver received it, switched to DATA1 and sent ACK, which (for example) was not accepted by the host, which is why the bit in DATA1 did not switch.

The host will send DATA0 again. And the device will acknowledge it with ACK, despite the fact that it expects DATA1. This is what the specification says.

Now regarding the USB controller in STM32F103 (in the paragraph about OUT/SETUP transactions):

"...
When the end of DATA packet is detected, the correctness of the received CRC is tested and only if no errors occurred during the reception, an ACK handshake packet is sent back to the transmitting host.
..."

That is, if no reception errors are detected, the device will send ACK. So far, from what has been written, it does not follow that nothing at all will be sent (silence), but let's assume.

"...
In case of wrong CRC or other kinds of errors (bit-stuff violations, frame errors, etc.), data bytes are still copied in the packet memory buffer, at least until the error detection point, but ACK packet is not sent and the ERR bit in USB_ISTR register is set. However, there is usually no software action required in this case: the USB peripheral recovers from reception errors and remains ready for the next transaction to come. If the addressed endpoint is not valid, a NAK or STALL handshake packet is sent instead of the ACK, according to bits STAT_RX in the USB_EPnR register and no data is written in the reception memory buffers.
..."

As far as I understand, a mismatch of the DATA toggle bit fits under "or other kinds of errors", so it would apply that an ACK is not sent.

But this is no longer true. There should be a special state controlling the DATA bit, and if there are no errors other than a mismatch of the toggle bits, then the peripheral should issue an ACK, but not issue an interrupt to the application software.

Next:

"...
If the length of the data packet payload (actual number of bytes used by the application) is greater than the allocated buffer, the USB peripheral detects a buffer overrun condition. in this case, a STALL handshake is sent instead of the usual ACK to notify the problem to the host, no interrupt is generated and the transaction is considered failed.
..."

Okay, this describes a case where the allocated receive buffer turned out to be smaller than what is actually in the received data frame.

"...
When the transaction is completed correctly, by sending the ACK handshake packet, the internal COUNT register is copied back in the COUNTn_RX location inside the buffer description table entry, leaving unaffected BL_SIZE and NUM_BLOCK fields, which normally do not require to be re-written, and the USB_EPnR register is updated in the following way: DTOG_RX bit is toggled, the endpoint is made invalid by setting STAT_RX = ‘10 (NAK) and bit CTR_RX is set. If the transaction has failed due to errors or buffer overrun condition, none of the previously listed actions take place.
..."

They write that if any errors occurred during reception, then none of the listed actions will be performed. If you reread the sentence, it becomes obvious that these actions include, among other things, issuing an ACK. Which again confirms the discrepancy with the USB specification.

Where is the truth?