how to implement USB device Vbus change event in ASF4 START?

Log in or register to post comments
Go To Last Post
3 posts / 0 new
Author
Message
bird-man
bird-man's picture
Level: Rookie
Joined: Thu. Jun 27, 2019
Posts: 45 View posts
Location: Tennessee, USA
#1
Posted by bird-man: Thu. Aug 8, 2019 - 04:24 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

According to USB standard Vbus sensing is the intended way to change the state of USB device when USB cable is connected to the USB Host if USB device is self powered .

Unfortunately USB examples for SAM E70/V71 family MCU , provided in the START using  ASF4 library do not handle Vbus change event. Even examples made for SAM V71 Xplained Ultra do not use Vbus sensing although that board has the GPIO pin wired to USB Vbus for sensing. START USB device configuration does not even have option to choose Vbus sensing even though we can choose self-powered USB device with remote wakeup which essentially implies need to change the USB state to "POWERED" when cable plugged in using Vbus sensing.

I can assign any GPIO pin as a digital input to be used for Vbus sensing and generate interrupt but how to register it to the USB device Callback event and create a handle for a USB_EV_VBUS event and what that Callback handle should do to change the USB state ?

Can anybody point me to an example of using Vbus sensing for USB connection change event in ASF4?

Correction:

the question should be re-phrased because GPIO pin state which senses the change of Vbus triggers it's own Interrupt (not USB device interrupt) , which in turn should call USB driver routines to change the USB state. So the correct question is what USB driver APIs should be called to change the USB state from within GPIO Interrupt ISR upon the Vbus change?

Tags:

Atmel SMART ARM-based MCUs and MPUs, Atmel Cortex-M MCUs, ASF4, USB, Vbus, sam, Atmel Start
Last Edited: Fri. Aug 9, 2019 - 03:22 PM
Top
sukuwc
sukuwc's picture
Level: Rookie
Joined: Tue. Dec 5, 2017
Posts: 36 View posts
Posted by sukuwc: Sat. Aug 10, 2019 - 09:02 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Does your application have a power source other than USB? If so you have to make sure that it can not feed power to the USB port (with a diode for example).  Self-Powered USB Device is usually a printer or other high powered device, these usually don't consume any power from the USB port.

 

You don't really need to sense the VBUS line, the micro will continuously try to enumerate. Most hosts these days don't really care, the are a 5V (1.5A or 3A max) Voltage sources with a polyfuse for short-circuit/overload protection. Since the introduction of countless smartphone charging "standards", the USB specification has very limited influence over what happens in the real world...

Top
bird-man
bird-man's picture
Level: Rookie
Joined: Thu. Jun 27, 2019
Posts: 45 View posts
Location: Tennessee, USA
Posted by bird-man: Sat. Aug 10, 2019 - 04:08 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thank you sukuwc for taking a note of this problem. This is far beyond the power management over USB. It's about embedded device functionality tight to the state of USB connection.

I am currently experimenting with SAME70 Xplained board. From the target USB view, the board is like "self powered" because it is powered over embedded debugger USB EDBG so it remains powered after target USB cable disconnected.

Not sensing Vbus leads to many problems regardless the power source.

The enumeration works fine without Vbus sensing as it is implemented on this development board but once the device ejected or cable disconnected, the host considers it is to be removed, yet the USB device is still in "configured" state, meaning the device does not "know" that it is disconnected. Now the functionality of the target USB device is messed up if it is tight to the USB. Depending on the code it can be in the dead loop, throw exception, or continue working fine until you try to re-connect USB cable -> then no success because USB device "thinks" it continues with the same connection handles while in fact host closed it down... total mess. USB MSC class mess : after host PC reports it is successfully ejected, the target USB device continues in the same state as if it is connected. Host PC does not remove it's port from the connected list because the device did not finish the ejection messaging sequence.

Proper USB Vbus sensing ensures the correct status of USB on both ends in relation to the enumeration and disconnection. Other SAM Cortex-M7 dev boards have Vbus USB line wired to the GPIO pins, yet surprisingly the USB examples provided for them do not take advantage of this. In all USB examples I found, the USB stack tries to "attach" immediately after the initialization and stays in the same state until  un-powered or reset - all regardless of  the cable been connected or not.

 

Top