STMicroelectronics / stm32f7xx_hal_driver

Provides the STM32Cube MCU Component "hal_driver" of the STM32F7 series.
BSD 3-Clause "New" or "Revised" License
26 stars 9 forks source link

STM32F723 does not trigger HAL_PCD_DataOutStageCallback for USB Audio on Windows #8

Open fxtentacle opened 3 weeks ago

fxtentacle commented 3 weeks ago

Dear STM team,

When I created a new STM32F723ZETx project (FW v1.17.2) with STM32CubeMx and selected USB audio, then it worked nicely on Linux, but AUDIO_PeriodicTC_HS was never called on Windows. I've verified that Windows is sending isochronous audio packets, which means the problem is caused by the STM32 HAL not triggering the appropriate callbacks despite the hardware receiving the data.

My impression is that this line:

https://github.com/STMicroelectronics/stm32f7xx_hal_driver/blob/52bfa97ba66afc08481f6fd7631322593bd89691/Src/stm32f7xx_hal_pcd.c#L1377

is trying to verify that the even/odd flag inside DOEPCTL is matching with the current frame number's parity. If that is the intention, then instead of

((RegVal & (0x1U << 16)) == (hpcd->FrameNumber & 0x1U)))

it should read

(((RegVal & (0x1U << 16)) != 0) == (hpcd->FrameNumber & 0x1U)))

because we want to check if the EONUM bit is set and not check for its absolute value. And, indeed, that small change repairs the HAL_PCD_DataOutStageCallback on Windows :smiley:

ALABSTM commented 3 weeks ago

Hi @fxtentacle,

Thank you for this report. The point looks valid. A question though please. After you changed the code in the hal_pcd.c file, did you try again on Linux to check everything is still OK?

With regards,

fxtentacle commented 3 weeks ago

Yes, the change had no influence on Linux where the HAL_PCD_DataOutStageCallback was being called both before and afterwards. My subjective impression is that Linux now has a slightly improved timing from when I connect the STM32 until when the audio device changes, but that's really hard to measure objectively.

ALABSTM commented 2 weeks ago

ST Internal Reference: 185291