Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Detection of disconnection #2

Open
FelixGruetzmacher opened this issue Jan 9, 2023 · 1 comment
Open

Detection of disconnection #2

FelixGruetzmacher opened this issue Jan 9, 2023 · 1 comment

Comments

@FelixGruetzmacher
Copy link

We are developing a USB device which, among other interfaces, provides ethernet via NCM with the help of your great library. It works beautifully.
However, we are running into a problem where the host sometimes decides to disconnect our device. We tested with other ethernet devices as well and saw the same disconnection behavior, so our device is not at fault (or at least shares this problem with others).
We are looking for a way (possibly a callback) to detect when the host disconnects from us. Unfortunately we cannot simply check VBUS as this pin is not handled by our main processor directly. Is there any way to ask how long ago the last transaction took place? We learned that not all transactions raise interrupts, so simply resetting a timer in the isr (as I ignorantly tried) won't do.
Any help is greatly appreciated.

@benedekkupper
Copy link
Member

benedekkupper commented Jan 10, 2023

First of all, great to hear that you are using this library, and feedback is always welcome! I'd also like to hear about the product once it makes it to the market :)

Regarding your question, I need some clarification before I can advise you on further steps. Namely I don't know what "the host disconnects our device" means in this context exactly.

  • Is the whole USB device disconnected, including no VBUS supply?
  • Or is the host sending a bus reset?
  • Or the disconnect is restricted to the NCM function inside the device?

It would also be a good idea to try to understand the reason why the host decides to do what it does, by looking at the OS logs. Which OSes produce this behavior?

You can also enable the SOF (start of frame) interrupts to see if they are also missing out when this disconnection happens, that would point to a power saving mode kicking in in the host OS. You can also use the device's Suspend and Resume callbacks to check this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants