USB charger with/without enumeration

⚠️
Hi there.. thanks for coming to the forums. Exciting news! we’re now in the process of moving to our new forum platform that will offer better functionality and is contained within the main Dialog website. All posts and accounts have been migrated. We’re now accepting traffic on the new forum only - please POST any new threads at//www.xmece.com/support. We’ll be fixing bugs / optimising the searching and tagging over the coming days.
5 posts / 0 new
Last post
matthieuW
Offline
Last seen:3 months 1 week ago
Joined:2015-11-20 14:55
USB charger with/without enumeration

HI Dialog,
i am working on a custom board implementing DA14681,
My system includes a lion battery and a usb cdc interface.
Thus i use the usb enumeration and the charger.
However when plugging a usb cable without enumuration (eg, phone charger) my system crashes after enumeration or a tentative enumeration and thus the battery is not charged.
Should i had some interrupts in the usb cdc callbacks?
Thanks for your help.

Device:
NV_dialog
Offline
Last seen:3 months 1 day ago
Staff
Joined:2015-07-15 14:58


Hi Mathew

We have tested the case on the ProDK.
We used the usb_cdc example, as is, out of the box in the latest SKD v.1.0.10.1072.
The example implements the CDC-Serial and charges the battery (if present).
We connected a Lithium battery to the button battery leads at the bottom of the daughterboard to verify the charging.
We tested it with :

  • a wall charger,
  • a laptop USB port using all pins and allow the enumeration
  • 笔记本电脑USB端口不枚举(只有通风装置/ GND connected)


In all case the operation was correct and no crash or battery charging failure observed.
You do not need to have any interrupts in the CDC.
Everything is handled in the Charger and USB code.

If our understanding is correct, you have this problem on your board, correct?
If this is the case, can you try the same scenario using the Dialog ProDK?

Please check the electical design and the connectors used in your design.
There are several restrictions required for USB connections.
If you are using some sort of craddle, please note that accorsing to USB standard, the VBUS and GND pins must be 2mm longer than the D+/D- in order to be connected first.disconnected last (before the D+/D- at least) to be compliant with ESB and USB design requirements.
In case where the D+/D- and VBUS are connected without the GND, then the ESD protection of the silicon will kick-in and ou might observe resets of the system or even temporary disabling of the USB subsystem.

Concuding:The CDC example in the 1.0.10.1072 SDK there is no problem with the CDC implementation or the charging.
In the SDK 1.0.8, there is bug fixed in the CDC which was triggered upon unplug of the device and this will lead to the system crash.
This is fixed in the 1.0.10 SDK.
We suggest you to move to 1.0.10 SDK as it included bug fixes and improvements.

Best regards.

matthieuW
Offline
Last seen:3 months 1 week ago
Joined:2015-11-20 14:55
Hi Dialog,

Hi Dialog,
i migrated my code to sdk10 with no improvement,
however i did check the usb_cdc code and it seems that the firmware blocks in the while condition waiting for usb to be configured at the beginning of the task,
removing this loop seems to be ok in my case for usb with and without enumeration.
Thanks for your help.

NV_dialog
Offline
Last seen:3 months 1 day ago
Staff
Joined:2015-07-15 14:58
Hi MathieuW.

Hi MathieuW.

Which while condition have you removed?

The whiles are there for a reason. It is not safe to remove them.

Cna you post the code snippet please?

BR/Nikos V.

matthieuW
Offline
Last seen:3 months 1 week ago
Joined:2015-11-20 14:55
Dear Nikos,

Dear Nikos,
I don't know why but the system_charger launch the usb cdc task whereas the is enumeration or not .

here is the loop i commented in the usb_cdc task, as the task does not wait for notification and is executed repetively, everything seems fine.

while (1) {
...

/* Wait for configuration*/
// while ((USBD_GetState() & (USB_STAT_CONFIGURED | USB_STAT_SUSPENDED))!= USB_STAT_CONFIGURED)
// USB_OS_Delay(10);

Best Regards
Matthieu