Reboot DFUDelay dfu failures

Technical questions regarding the XTC tools and programming with XMOS.
User avatar
mon2
XCore Legend
Posts: 1913
Joined: Thu Jun 10, 2010 11:43 am
Contact:

Post by mon2 »

random thought...
With HID enabled, too many threads running and tanking the USB IP due to lower bandwidth? However, thought that the XCORE-200 processors no longer have the min bandwidth requirement for USB but my memory may be fading here.

Does the HID leg of the IP work ok? Is the HID code factory fresh from XMOS? If not, consider to import a proven code run for the HID support from XMOS and test again.

Check the resources being used by your IP to rule out if bandwidth is a factor.


User avatar
mon2
XCore Legend
Posts: 1913
Joined: Thu Jun 10, 2010 11:43 am
Contact:

Post by mon2 »

Hi. Be sure the following is not impacting your current design:

http://www.xcore.com/viewtopic.php?f=37&t=6460

Code: Select all

http://www.xcore.com/viewtopic.php?f=37&t=6460
MyKeys
Active Member
Posts: 33
Joined: Mon Jul 03, 2017 9:41 am

Post by MyKeys »

Good points, but unfortunately the HID follows the reference design and runs on the buffer thread.
There are 5 cores running each at 100MHz on the XUD tile. The HID works as expected (mouse scroll wheel).

I tried with the exact same HID setup as the ref firmware but it behaves the same.

I also tried disabling the HID reports by not ever calling XUD_SetReady_In() for the endpoint but still the same results.

Changing tack I switched to the xmos multichannel audio reference board and ref firmware with some tweaks to make it appear similar in bandwidth/channel counts but it unfortunately behaves fine in regards to dfu (audio thread doesn't cope but that's to be expected).

The last thing I'm going to try is reducing the channel counts and bandwidth to see if this has any impact otherwise I'm slowly running out of ideas here.

Appreciate all the help mon2,
Mike.
User avatar
mon2
XCore Legend
Posts: 1913
Joined: Thu Jun 10, 2010 11:43 am
Contact:

Post by mon2 »

How goes this battle? Any remedies?

Is your widget powered by the USB port or self-powered using an external power supply?

What is the current draw for your widget?

Is the power sequencing and reset circuit sound on the hardware? You noted that removal of the USB cable and re-docking appear to fix the enumeration of the device so questioning if the reset circuit is correct.

What is the color of the plastic insulator of the USB ports that work? Keep in mind that often, black insulator ports are limited to 100/500 mA current draw. Blue insulator are often 900mA (USB 3.0 / aka USB 3.1 Gen1).

Red are usually power only ports but often around 1A-2A for charging only ports. The red ports may also have data lines for standard USB use.

Perhaps you require more current for your device so only specific USB ports work correctly?

During the DFU process, how far down this process can you proceed with your hardware?
MyKeys
Active Member
Posts: 33
Joined: Mon Jul 03, 2017 9:41 am

Post by MyKeys »

In speaking with Thesycon it seems a device must wait a minimum of 500ms before reconnecting. This explains the DfuDelay and I suspect the 50ms delay is a typo in the XMOS ref design.

They have suggested trying to increase this delay as it maybe necessary when a hub is used possibly with a HID endpoint.

I'm not quite sure on the reconnect process but increasing DfuDelay to 1 second does not fix the issue which currently only stalls the endpoint0 core.
If I instead add a delay to the startup of the XUD tile then so far things seem to work (touch wood).
I still have to do a few more tries to be confident.

I see XUD_U_SERIES devices have a register to disconnect from the bus and this is called after the DfuDelay which doesn't sound right?

Mike.
MyKeys
Active Member
Posts: 33
Joined: Mon Jul 03, 2017 9:41 am

Post by MyKeys »

So 50 updates so far and everything looks good :)
The device is self-powered by the way and power sequencing had been thoroughly checked.
I'd like to see someone from XMOS respond in regards to the reasoning for DFUDelay with differing times and why it happens before the reboot where presumably the device is still connected to the bus?
Maybe an email is in order.

Mike.
Post Reply