STM32L1 (USBv1): Wrong DTOG_RX interpretation for isochronous transfers? Topic is solved

[WowSuchName]

Hi,

I'm currently implementing an isochronous data stream using UAC2 in asynch mode on an STM32L1 controller. To match the data rates, every once in a while an additional sample is transferred over the bus and this is where I get data corruption. Since I successfully ran the code on an STM32F4 (there might be another bug to report, but not entirely convinced yet), I suspected the driver code.

But first of all the basic data:

- ChibiOS version or subversion revision number: RT+HAL ver21.11.1 (same git tag)
- Compiler: arm-none-eabi-gcc 11.2.0
- Platform and board: STM32L151CB6A on a custom board (I have not yet noticed any CRC errors)
- Nature of the problem: Data corruption when using isochronous out transfers
- Failure mode: see below.


The long way around:

When I receive the additional sample (10 bytes vs. 20 bytes in this specific case), the driver reads garbage from the USB packet memory (PMA). I suspect that the DTOG_RX bit is interpreted the wrong way round and thus the driver tries to access the data in the wrong frame. This behaviour would lead to a corrupt first packet, which would go unnoted by my application code (I toss some packets upon first reception). Changing hal_usb_lld.c:146 from

if (EPR_EP_TYPE_IS_ISO(epr) && !(epr & EPR_DTOG_RX))

to

if (EPR_EP_TYPE_IS_ISO(epr) && (epr & EPR_DTOG_RX))

seems to remedy the issue. (I'm echoing the data back to the bus and get an off-by-one later on, but I suspect there is an issue in my code as well. The data contains a sequence counter which tells me that the samples arrives in the correct sequence from the bus and the issue lies in buffering/retransmission.)

I'm not too familiar with the USB peripheral, but the reference manual (RM0038, Rev 16) states the following:

1. Table 101 (p. 599) is in accordance with the comment in hal_lld_usb.c (DTOG_RX points to the buffer used by the USB peripheral).
2. From the bit description (bit 14 on p. 610): "If the endpoint is Isochronous, [...] [h]ardware toggles this bit just after the end of data packet reception [...].". In particular, I'm not sure if that means before or after the interrupt is issued.


TL;DR: I'm not that certain which way around the DTOG_RX bit must be interpreted, however negating the condition the driver seems to remedy the issue for me. Maybe someone with more experience could have another glance?

Thanks in advance!


Cheers

[Giovanni]

Hi,

I never tested isochronous mode in the driver, it has been contributed and just included as-is. If you are sure about this change then I will include it.

Lets wait for more comments. I will give a look to manuals anyway.

Giovanni

[Giovanni]

Hi,

Driver USBv2 had the condition as you suggested already, fixed in USBv1.

Fixed as bug #1232.

Giovanni