Force a Re-enumeration request
-
shaw
- Experienced Member
- Posts: 64
- Joined: Fri Mar 25, 2011 12:36 am
Force a Re-enumeration request
We are developing a product based on USB Audio Reference software, version 8.1.0. We have a need to be able to update the connected PC with new device configuration information, after initial Power Up. Is there any way within the software to force a "Soft Disconnect" or "Soft Detach" to request that the PC initiate a re-enumeration request?. Thanks for any help.
-
Ross
Verified - XCore Legend
- Posts: 1163
- Joined: Thu Dec 10, 2009 9:20 pm
- Location: Bristol, UK
The quickest way to do this would be the detach functionality already present in the DFU functionality, I should imagine.
What OS’s do you need to do this from?
What OS’s do you need to do this from?
Technical Director @ XMOS. Opinions expressed are my own
-
shaw
- Experienced Member
- Posts: 64
- Joined: Fri Mar 25, 2011 12:36 am
primarily Windows. Maybe mac.
-
Ross Verified
- XCore Legend
- Posts: 1163
- Joined: Thu Dec 10, 2009 9:20 pm
- Location: Bristol, UK
Are you licensing the Thesycon driver? Or using Windows built in? Asking because the host code will be slightly different.
Technical Director @ XMOS. Opinions expressed are my own
-
shaw
- Experienced Member
- Posts: 64
- Joined: Fri Mar 25, 2011 12:36 am
licensing the Thesycon driver
-
Ross Verified
- XCore Legend
- Posts: 1163
- Joined: Thu Dec 10, 2009 9:20 pm
- Location: Bristol, UK
The easiest was to achieve a detach/re-attach is to cause the device to reboot - this may or may not be acceptable based on product.
You could add a custom request to the device to do such a thing. However, using the standard DFU interface to move into DFU and then move back to application mode (i.e. two reboots) would give the desired functionality (I think..) without any code modifications or device or host. Just a thought.
You could add a custom request to the device to do such a thing. However, using the standard DFU interface to move into DFU and then move back to application mode (i.e. two reboots) would give the desired functionality (I think..) without any code modifications or device or host. Just a thought.
Technical Director @ XMOS. Opinions expressed are my own
-
shaw
- Experienced Member
- Posts: 64
- Joined: Fri Mar 25, 2011 12:36 am
What is the recommended way to initiate the reboot from within the XMOS code? (XU316-1024-FB265-C32 and v8.1.0 USB audio ref. code)
-
Ross Verified
- XCore Legend
- Posts: 1163
- Joined: Thu Dec 10, 2009 9:20 pm
- Location: Bristol, UK
A write to the pll control register. Here's some example code: https://github.com/xmos/lib_xua/blob/de ... /reboot.xc
Technical Director @ XMOS. Opinions expressed are my own
-
shaw
- Experienced Member
- Posts: 64
- Joined: Fri Mar 25, 2011 12:36 am
that did it, thank-you
-
shaw
- Experienced Member
- Posts: 64
- Joined: Fri Mar 25, 2011 12:36 am
An additional follow-up question. The reboot works successfully as intended. Now we would like to write a "magic number" to RAM before reboot, maybe a couple bytes. Then reboot and finally retrieve the "magic number" following reboot.
Since RAM retains power during reboot, it should be able to retain data. Is there a section of RAM that can be written and not reinitialize during startup ram init. Or maybe something just read in startup before RAM initialization.
Is there way to do this with the existing startup file OR maybe edit the startup file?
Thanks,
Since RAM retains power during reboot, it should be able to retain data. Is there a section of RAM that can be written and not reinitialize during startup ram init. Or maybe something just read in startup before RAM initialization.
Is there way to do this with the existing startup file OR maybe edit the startup file?
Thanks,