TARGET_STM: fix unterminated multi-packet USB transaction

[daniel-starke]

Summary of changes

Fix issue #15384 by sending a zero-length packet if the packet sent had the same size as the endpoint buffer size. This is needed to comply with the USB protocol which assumes an ongoing multi-packet USB transaction otherwise.

STM32 HAL PCD handle parameters are used to avoid data duplication in RAM.

Impact of changes

Affects all STM32 targets with USB device support.

Documentation

None

---

Pull request type

[x] Patch update (Bug fix / Target update / Docs update / Test update / Refactor)
[] Feature update (New feature / Functionality change / New API)
[] Major update (Breaking change E.g. Return code change / API behaviour change)

---

Test results

[] No Tests required for this change (E.g docs only update)
[x] Covered by existing mbed-os tests (Greentea or Unittest)
[] Tests / results supplied as part of this PR

Further tests would be desirable but require actual hardware.
Basic function test has been performed with NUCLEO-H723ZG.

---

[0xc0170]

@jeromecoutant could you review please?

[jeromecoutant]

@jeromecoutant could you review please?

I have noticed this PR in #15384 , so let's wait for some time ?

[jeromecoutant]

Maybe ACI can be started ?

[0xc0170]

CI started (server was restarted, itshould trigger now)

[mbed-ci]

Jenkins CI Test : ✔️ SUCCESS

Build Number: 1 | 🔒 Jenkins CI Job | 🌐 Logs & Artifacts

CLICK for Detailed Summary

jobs	Status
jenkins-ci/mbed-os-ci_build-cloud-example-GCC_ARM	✔️
jenkins-ci/mbed-os-ci_build-cloud-example-ARM	✔️
jenkins-ci/mbed-os-ci_unittests	✔️
jenkins-ci/mbed-os-ci_build-greentea-ARM	✔️
jenkins-ci/mbed-os-ci_build-greentea-GCC_ARM	✔️
jenkins-ci/mbed-os-ci_build-example-ARM	✔️
jenkins-ci/mbed-os-ci_build-example-GCC_ARM	✔️
jenkins-ci/mbed-os-ci_greentea-test	✔️

[0xc0170]

Back to review, There was a comment in the issue referenced above, what do you think?

[daniel-starke]

It was my concern in the very beginning that changing this on target side might be inappropriate. Usually, the hardware does not know whether we want to perform a multi-packet transaction or not. Hence, the PHY has no way to determine whether to send a ZLP or not. But there may be devices out there that ignore this fact and disallow multi-packet transaction by always terminating all transactions after a single packet by auto send ZLP.
Still, better to send double ZLP than run into a dead-lock.

[cyliangtw]

Hi @daniel-starke,
Could you have a look #15473, could it resolve your issue ?

[daniel-starke]

Hi @cyliangtw,
It looks good from as far as I can see it. Did you run some tests with an STM device?

[cyliangtw]

Hi @cyliangtw, It looks good from as far as I can see it. Did you run some tests with an STM device?

I have no STM device on hand, so I verified it on NuMaker-IoT-M467 device.
Anyway, this PR is not independent of specific device, it's general for USBD, such like as usb serial.

[daniel-starke]

I know. Just wanted to make sure that there is no target specific code blocking this function. I will try it on a NUCLEO-H723ZG later on.

[daniel-starke]

Closing this pull request. See #15473.