USB - FTDI emulation #889
Comments
|
Quite possibly, got some links? |
|
It's in my Mostly it's only changed descriptor and fake modem/line status appended to each IN packet ... and code to ACK commands Not tested with newest FTDI driver (the one killing fake FTDI chips) |
|
Sounds like a good plan. The STM VCP Driver is not woking well on some systems. From our experiance with the AlienWii F3 some systems are able to connect imediately after an reboot of the firmware others require a complete disconnect and reconnect. This probllem only exist on windows. |
|
CC3D generally requires you to unplug and disconnect after any reboot, makes it hard to do i.e. esc calibration or even upgrading the firmware. |
|
Since the configurator now disconnects and in my case auto-reconnects I'm not seeing the immediate need to have it implemented differently. What I noticed before this was the case. If you would reboot in cli tab and directly pressed disconnect, the COM port would remain available, if I didn't apply that trick, I could still disconnect, but the COM port would dissapear from the drop down list, which can then be solved by unplugging and plugging the board. So in short, I think this issue is already adressed. |
|
For me i always need to reconnect manualy after the FC is rebooting. Fortunaltely my systems recocnize always the USB port again ´without repower the FC. We havé seen quite some systems wich realy need an disconnect to find ´the USB port again on windows. The FTDI driver is much more reliable than the STM VCP driver. |
|
I started this because I must close serial and reconnect Sparky after each reboot with STM drivers ... FTDI almost works, only some kind of port enumeration hangs until port is disconnected. Probably missing status packet on IN endpoint ... |
|
This is the behavior we have seen on quite some machines and we are not able to resolve. We have fund this is a driver problem and will only happen on windows. Likely all targets which are using the STM32 bulid in USB port will be affected (Sparky, Discovery F3, Naze32 Pro, AlienWii F3, CC3D, SP Racing F3). |
|
I've been working with the Atmel SAM4S (ARM Cortex M4) for a university project recently. The Atmel implementation suffers the same problem. A little light reading indicates the problem lies in the Windows USB serial driver, USBSER.SYS. I've been wondering if perhaps just disabling the pullup on the DP line for a short time during boot might force Windows to see the USB device disconnect and re-enumerate it when the pullup is re-enabled? I'll try this on the Atmel MCU and see if it works. |
|
Okay, I have tested setting the DP line to open drain for a short time on the SAM4S and it does indeed force the USB device to be re-enumerated and can successfully be connected by the configurator afterwards as long as it wasn't connected when the reboot occurred. My next step is to look at disconnecting the CDC ports in the ResetHandler to try and remedy this too...? The code: void usb_cdc_init(void)
{
/* This is a slight hack to force Windows to re-enumerate
* the USB device. The DP line is set to open drain for
* 1 ms (the USB 2.0 spec says 2.5 us is enough) so that the
* device is detected as disconnected, the pullup is then
* re-enabled so that USB2.0 full speed mode is enabled.
*/
// Set the DDP pin to PIO rather than USB
uint32_t sysIO = matrix_get_system_io();
sysIO |= 1 << 11;
matrix_set_system_io(sysIO);
// Set to open drain for a short time then re-enabled pullup
ioport_set_pin_mode(USB_DDP_PIN, IOPORT_MODE_OPEN_DRAIN);
systick_mdelay(1);
ioport_set_pin_mode(USB_DDP_PIN, IOPORT_MODE_PULLUP);
// Restore DDP pin to USB function
sysIO &= ~(1 << 11);
matrix_set_system_io(sysIO);
// Start USB stack to authorize VBus monitoring
udc_start();
}I'm sure something similar is possible on the STM32. |
|
IMO USB device is reenumerated on CF reset. But the driver does not handle this well if port is open |
|
Aha, different problem then. :-( |
|
@tracernz, that seems to be the same behavior as I had with the Sparky board. When manually disconnecting (with button in configurator), just before re-enummeration I managed to have it working. But as stated before, somehow all is working fine now on my Windows 8.1 machines and development branch firmware and configurator. |
|
I got W7-64 here ... Maybe 8.1 got this right? I hit some problem with FTDI - one sparky almost works, another does not ... One possibility would be to use two serial numbers in driver - two serial ports will be created, so you can close old and open new one ... ugly, but a bit better than disconnecting USB on each reboot ... |
|
The problem also happens on Windows 8.1. Looks to be not related to the OS itself. We have machines working and others not. We always need to reconnect the CF configurator after the reboot of the FC. But on some machines an physical reconnect of the USB is required. |
|
Windows 10 also have problems with the CC3D, have to reconnect the USB all the time. Fixing this will get a big thumbs up from me :) |
|
Since the embedded USB contollers will be reinitialized during reboot the FC will always disconnect. This is also the same for other cleanflight targets wich using the internal USB port of the STM32 like the AlienWii F3, Sparky or Discovery F3. |
|
What about two-port approach? It would almost solve this issue ... |
|
I was testing the new DFU flash mode with Sparky (see cleanflight/cleanflight-configurator#250) and it works just fine. However, the normal reboot doesn't. I have to reconnect USB. As suggested above, if you click Disconnect button in the Configurator just after triggering Reboot, then you can reconnect back without reconnecting USB. I guess that the new Motolab FC will be also affected (ping @MotoLab). Also found a software way to make it work. Disable virtual com port device via Device Manager and then enable it back, port reappears in the Configurator and you can connect again. |
|
Reconnecting automatically when VCP boards reboot is a case of altering the configurator code a little so it will lookout for the VCP device coming back and reconnect when it does. Currently, when the VCP device/port dissappears it will disconnect and then do nothing. Probably need a callback set on device discovery (that will check if the new device is the same as the last connected device) and a timer to clear it (so it doesn't auto-reconnect when you actually physically disconnect and plug in again some time later). I think there are some situations where the device discovery doesn't work correctly on Windows though so that may be a seperate issue. I certainly haven't seen that issue on Linux or OS X. |
|
The problem is actually that both windows and configurator don't disconnect when the device reboots. Both keep acting as if it was still connected and just not responding. |
|
I think that this is a core windows problem with serial port emulation Systems with the serial port open at the point where the hardware You see exactly the same symptoms when connecting to a bluetooth device On 17 October 2015 at 08:13, Arakon notifications@github.com wrote:
|
|
One potential solution would be to put a delay in the firmware code before it actually reboots, giving the configurator time to disconnect properly before the port goes away? |
|
This needs fixed to disconnect the device too (if VCP): https://github.com/tracernz/cleanflight-configurator/blob/master/tabs/ports.js#L258, probably also the CLI although it might not be worth the effort since it's going to be removed. We know if the board is VCP since cleanflight/cleanflight-configurator@e4f47f8 so we can do VCP specific stuff. |
Don't allow MSP_REBOOT and MSP_SET_4WAY_IF to execute when ARMed
It is possible to emulate FTDI chip on STM32F303. That way sparky connects as FTDI converter. FTDI driver is considerably better that ST CDC demo, it handles reset gracefully (just reconnect in configurator) etc.
Is it worth working on?
The text was updated successfully, but these errors were encountered: