Usb device init: wait_us fix

[vvkaggarwal12]

Summary of changes

"fixes #13203"
In usb device phy initialization, ThisThread::sleep_for changed to wait_us.
As before the usb phy is initialized, all the interrupts are disabled, so sleep_for is not supported.
USB device was not getting enumerated as a result of this delay.
Calling wait_us will resolve the issue.

Impact of changes

Migration actions required

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

---

Reviewers

---

[0xc0170]

I previously only read a comment about 2.5uS and we had there 300 ms delay? This is quite a long delay. Wouldn't be sufficient to just a spin for 1ms?

[0xc0170]

900 should be sufficient based on the comment

[vvkaggarwal12]

900 should be sufficient based on the comment

Yes 900us should be sufficient. Previously it was 300ms, so given that much.
Updated the pull request with 900us.

[kjbracey]

If interrupts are disabled, shouldn't really be waiting for 900us either. That's enough to cause many characters of serial loss.

But why do you think interrupts are disabled? Where is this being called from? (If interrupts were disabled, I would expect the sleep_for to have generated an assert, not just "USB device was not getting enumerated" as described.

And where did "900us" come from? Only comment I can see says "2.5us".

[vvkaggarwal12]

Have a look at issue number:
#13203
Earlier delay given was 300ms. As mentioned in the comments, i given 900us.

[vvkaggarwal12]

Should I implement mutex solution for this and give a pull request?

[0xc0170]

I'll ask Russ why USBDevice lock implements critical section, will get back

[0xc0170]

Thinking about this. as the comment states 2.5us minimal, therefore waiting here 3us should be sufficient (there could be just typo and 300ms applied instead earlier).

The USB Device should be interrupt safe, thus locking the way it is. I propose to wait 5us to be on the safe side (stating that in the commit message to be clear).

[vvkaggarwal12]

Thinking about this. as the comment states 2.5us minimal, therefore waiting here 3us should be sufficient (there could be just typo and 300ms applied instead earlier).

The USB Device should be interrupt safe, thus locking the way it is. I propose to wait 5us to be on the safe side (stating that in the commit message to be clear).

I will change the delay to 5us then.

[vvkaggarwal12]

I'll ask Russ why USBDevice lock implements critical section, will get back

Ok martin, Could you please update here, if mutex needs to be implemented for this.

[ciarmcom]

@vvkaggarwal12, thank you for your changes.
@maclobdell @ARMmbed/mbed-os-maintainers please review.

[kjbracey]

Fine, but doesn't need to be 5 commits :)

[0xc0170]

@vvkaggarwal12 if you can squash all into one commit ? I can run CI asap

Pull request has been modified.

[vvkaggarwal12]

@vvkaggarwal12 if you can squash all into one commit ? I can run CI asap

@0xc0170 squashed all commit into single.

[0xc0170]

CI started

[mbed-ci]

Test run: SUCCESS

Summary: 6 of 6 test jobs passed
Build number : 1
Build artifacts