Hi folks,
A feature of several of our products is that the user can select whether the USB interface enumerates as UBS 1 or USB 2 (Full Speed or High Speed) device. There is an Input pin connected to a switch that is sampled at boot time and so the level of that input pin determines whether XUD_Manager is called with XUD_SPEED_FS or XUD_SPEED_HS.
But also, the application monitors the state of that switch and if it changes then a reboot is initiated. I've been successful at implementing this on two other XMOS processor models: L1 and SU1. For the L1, the application initiates a re-boot by forcing the assertion of the reset pin; and of course the PHY is a separate IC. On the SU, the application calls device_reboot_aux(); For both, the re-boot and re-enumeration works as desired every time.
I'm now working on a new product using the XU208 and there are mixed results using device_reboot_aux(); On some computes, the reboot always works and results in re-enumeration at the desired speed. But on many computers, re-enumerating at High Speed (changing from Full Speed) doesn't work but results in re-enumerating again at Full Speed. There is no correlation whether it's Windows (10, 8, 7) or OSX. It's just that some computers do and some don't. One of our computers never even recognizes the re-enumeration at all. I've tried write_periph_32( usb_tile, 1, 0x50, 1, write_data); to reset the PHY prior to calling device_reboot_aux(). I've tried adding delays at various places. It seems that the PHY on the XU2 somehow behaves differently from the PHY in the SU1.
Any idea on a solution? thanks
XU208 - USB re-enumeration by device_reboot_aux() but changing USB speed from FS to HS
[quote="Caleb"]Hi folks,
A feature of several of our products is that the user can select whether the USB interface enumerates as UBS 1 or USB 2 (Full Speed or High Speed) device. There is an Input pin connected to a switch that is sampled at boot time and so the level of that input pin determines whether XUD_Manager is called with XUD_SPEED_FS or XUD_SPEED_HS.
But also, the application monitors the state of that switch and if it changes then a reboot is initiated. I've been successful at implementing this on two other XMOS processor models: L1 and SU1. For the L1, the application initiates a re-boot by forcing the assertion of the reset pin; and of course the PHY is a separate IC. On the SU, the application calls device_reboot_aux(); For both, the re-boot and re-enumeration works as desired every time.
I'm now working on a new product using the XU208 and there are mixed results using device_reboot_aux(); On some computes, the reboot always works and results in re-enumeration at the desired speed. But on many computers, re-enumerating gimp freejobalert notepad++ at High Speed (changing from Full Speed) doesn't work but results in re-enumerating again at Full Speed. There is no correlation whether it's Windows (10, 8, 7) or OSX. It's just that some computers do and some don't. One of our computers never even recognizes the re-enumeration at all. I've tried write_periph_32( usb_tile, 1, 0x50, 1, write_data); to reset the PHY prior to calling device_reboot_aux(). I've tried adding delays at various places. It seems that the PHY on the XU2 somehow behaves differently from the PHY in the SU1.
Any idea on a solution? thanks[/quote]
I also need help with these issues. Help is highly appreciated,
Thanks in advance,
Regards,
Rico
A feature of several of our products is that the user can select whether the USB interface enumerates as UBS 1 or USB 2 (Full Speed or High Speed) device. There is an Input pin connected to a switch that is sampled at boot time and so the level of that input pin determines whether XUD_Manager is called with XUD_SPEED_FS or XUD_SPEED_HS.
But also, the application monitors the state of that switch and if it changes then a reboot is initiated. I've been successful at implementing this on two other XMOS processor models: L1 and SU1. For the L1, the application initiates a re-boot by forcing the assertion of the reset pin; and of course the PHY is a separate IC. On the SU, the application calls device_reboot_aux(); For both, the re-boot and re-enumeration works as desired every time.
I'm now working on a new product using the XU208 and there are mixed results using device_reboot_aux(); On some computes, the reboot always works and results in re-enumeration at the desired speed. But on many computers, re-enumerating gimp freejobalert notepad++ at High Speed (changing from Full Speed) doesn't work but results in re-enumerating again at Full Speed. There is no correlation whether it's Windows (10, 8, 7) or OSX. It's just that some computers do and some don't. One of our computers never even recognizes the re-enumeration at all. I've tried write_periph_32( usb_tile, 1, 0x50, 1, write_data); to reset the PHY prior to calling device_reboot_aux(). I've tried adding delays at various places. It seems that the PHY on the XU2 somehow behaves differently from the PHY in the SU1.
Any idea on a solution? thanks[/quote]
I also need help with these issues. Help is highly appreciated,
Thanks in advance,
Regards,
Rico
Correct me if I'm wrong, but it's only the reboot feature that doesn't work? If you power the device on in HS or FS mode for the input pin that's perfect, it's just changing from FS to HS (during operation, without power cycling) that doesn't work?
Yes that was my experience with the XU208 device. I've had no such issue with the XS1-U8.