View previous topic :: View next topic |
Author |
Message |
betito131904
Joined: 19 Sep 2012 Posts: 5 Location: Mexico city.
|
4550 USB disconnect software but still physical connection |
Posted: Wed Sep 19, 2012 11:18 am |
|
|
Hi, I am working with a PIC18F4550 to connect by USB to a Computer.
At the computer it use JAVA(USB not USART) and at the PIC it use CCS.
The problem is that my hardware is still under development and it is unstable without enough electromagnetic protection then when a big motor is used in the same room, the PIC lose communication but the "connection sense pin" still high all the time.
To solve this connection problem, the PIC sends a message every 10 seconds and wait to an answered, if the PC does not answered, then it is know that something is wrong and the PIC call the "usb_init_cs()" to establish the connection. ( and it is working ok) but sometimes it lose data for many seconds.
Today I read that for a USB connection to a PC USART, it exist the same disconnection problem and could be detected by
if (usb_cdc_carrier.dte_present)
Here is the link: http://www.ccsinfo.com/forum/viewtopic.php?t=47940&highlight=reliability+usb
My question is:
Does it exist a method like (usb_cdc carrier.dte present) for those who does not use <usb_cdc.h> for USB connection?
Thanks
Roberto |
|
![](templates/subSilver/images/spacer.gif) |
Ttelmah
Joined: 11 Mar 2010 Posts: 19359
|
|
Posted: Wed Sep 19, 2012 12:10 pm |
|
|
I think you are misunderstanding a lot about USB...
The PC is the master device and does _everything_. The slave can't connect itself. USB_INIT_CS, won't connect the device, it just makes it _possible_ for the PC to connect to it. If connection has been lost, it will do nothing.
The DTE present ability, is again down to the master. The CDC driver in the PC has an option to activate DTE, when a connection is opened. You could do a similar thing with any USB device, by sending a control packet when a connection is made, but it is up to the PC application is to send this, and the PC application is the only thing that can re-open the connection. You'd have to have the PC code automatically close and re-open the device if data is not seen after an interval. Attempting to stop and re-open a device at the slave that is already open will result in a second different device appearing, which will not connect to the already open link....
Best Wishes |
|
![](templates/subSilver/images/spacer.gif) |
Darren Rook
Joined: 06 Sep 2003 Posts: 287 Location: Milwaukee, WI
|
|
Posted: Wed Sep 19, 2012 3:50 pm |
|
|
Ttelmah wrote: | I think you are misunderstanding a lot about USB...
The PC is the master device and does _everything_. The slave can't connect itself. USB_INIT_CS, won't connect the device, it just makes it _possible_ for the PC to connect to it. If connection has been lost, it will do nothing.
The DTE present ability, is again down to the master. The CDC driver in the PC has an option to activate DTE, when a connection is opened. You could do a similar thing with any USB device, by sending a control packet when a connection is made, but it is up to the PC application is to send this, and the PC application is the only thing that can re-open the connection. You'd have to have the PC code automatically close and re-open the device if data is not seen after an interval. Attempting to stop and re-open a device at the slave that is already open will result in a second different device appearing, which will not connect to the already open link....
Best Wishes |
True - but he could call usb_detach() followed by a usb_init_cs(). If the PC is still alive it should detect a detach on usb_detach() and then a re-attach on usb_init_cs(). That seems to be what he is asking.
But then after the usb_init_cs(), it's up to the computer to reconnect - if it is still alive. _________________ I came, I saw, I compiled. |
|
![](templates/subSilver/images/spacer.gif) |
betito131904
Joined: 19 Sep 2012 Posts: 5 Location: Mexico city.
|
|
Posted: Wed Sep 19, 2012 4:08 pm |
|
|
Ttelmah, thank you for your fast reply and explanation.
The PC application already have code to automatically close and reopen the device, but it still needs something else from the PIC.
Next, I try to explain the behavior of the problem and actual solution.
Time 1
PC -- USB OK
PIC -- USB OK
Time 2
External motor ON
Time 3
PC application detect USB connection fails, but windows XP does not detach the device (no USB detach sound).
PIC -- USB OK (my world is perfect)
Time 4
PC -- try to connect to the USB device without receive an answer.
PIC -- "USB OK" but after x time I will send a message to the PC
Time 5
PC -- try to connect to the USB device without receive an answer.
PIC --> send a message to the PC and wait for answer.
Time 6
PC -- try to connect to the USB device without receive an answer.
PIC --> time out error, PC does not receive PIC's message.
Time 7
PC -- try to connect to the USB device without receive an answer.
PIC call --> usb_init_cs()
PIC call --> usb_task();
Time 8
PC USB -- OK
PIC USB -- OK
I think what it is doing now it's remove PIC from the USB bus and then attach it to the usb bus and it is working again.
I think some how the PIC is malfunction, but when I call again the next functions
usb_init_cs()
and
usb_task();
I think that it is calling usb_detach(), and usb_attach(), then the PC can communicate with the PIC again.
I am not 100% sure about detach and attach to the bus is what it is really happened.
What do you think it is happening?
The PIC and compiler have any better way to detect when this kind of situation is happening? |
|
![](templates/subSilver/images/spacer.gif) |
Tom-H-PIC
Joined: 08 Sep 2003 Posts: 105 Location: New Castle, DE
|
|
Posted: Wed Sep 19, 2012 8:15 pm |
|
|
I have used the CCS USB CDC stack for years.
I have used it with motor drivers and all types of things.
So I don’t think it is the monitor that is the issue.
The only time I had issues is when I did not do thing in a timely fashion.
You need to loop through the usb_task(); about every 15 to 20 ms.
Are you doing that?
If not the PIC will not stay connected to the PC terminal program.
So if your software goes off in to a sub function and your not call usb_task(); in that function and it is to long the PC will drop the connect to the PIC.
Tom |
|
![](templates/subSilver/images/spacer.gif) |
betito131904
Joined: 19 Sep 2012 Posts: 5 Location: Mexico city.
|
|
Posted: Thu Sep 20, 2012 9:07 am |
|
|
Thank you Darren, the code after losing communication is doing usb_detach() followed by a usb_init_cs() "attach".
I want to detect as fast as possible the moment when losing communication, but the USB is connected all time, then usb task() do not detect any physical detach.
Thank you Tom, the code has a loop and the USB_task(); inside, it works perfect for USB fiscal detach, but I don't know if it is called every 15 or 20 ms, I think it is called faster but I really don't know the exact time, I will try to measure. thank you.
We will continue the development Hardware and Software (only USB), and I will share our results. Thank you all guys !! |
|
![](templates/subSilver/images/spacer.gif) |
betito131904
Joined: 19 Sep 2012 Posts: 5 Location: Mexico city.
|
|
Posted: Wed Sep 26, 2012 7:53 pm |
|
|
Problem solved.
I have an PC application in JAVA, connected by USB.
The problem was solved from the PC JAVA software, I am using ICASTE driver, this driver detected an error when I turn on a drill press near the computer.
To solve this I only need to use a call to a JAVA icaste API named "deviceReset()", I think this function restart some USB parameters of the PIC USB connexion, but it does not make a new enumeration or detach, then it is very good news !!
Unfortunately, the manufacturer does not give more information about this function, then I can comment only this.
Thank you all for your help. |
|
![](templates/subSilver/images/spacer.gif) |
FvM
Joined: 27 Aug 2008 Posts: 2337 Location: Germany
|
|
Posted: Thu Sep 27, 2012 8:59 am |
|
|
As a first point, I think Roberto is right that electrical interferences can cause a transmission error which
in return is answered by the host with stopping the USB communication. Not servicing the USB interface in
your firmware over some time will have the same result, however. It's also right that detaching the device
(by disabling the USB controller) and re-attaching it will reactivate the connection.
Now the problem is how to detect this situation on the device side. IMHO it will show by a missing 1 ms
SOF interrupt tick, which can be easily checked. |
|
![](templates/subSilver/images/spacer.gif) |
betito131904
Joined: 19 Sep 2012 Posts: 5 Location: Mexico city.
|
|
Posted: Thu Sep 27, 2012 5:01 pm |
|
|
FvM, you have a good idea!!!!
I will try to check the SOF interrupt. _________________ Roberto |
|
![](templates/subSilver/images/spacer.gif) |
Ttelmah
Joined: 11 Mar 2010 Posts: 19359
|
|
Posted: Fri Sep 28, 2012 2:29 am |
|
|
The 'handler' for this is in PIC18_USB.C, and is called usb_isr_sof. Currently does nothing unless debugging is enabled. Ideally do a test on a timer for it having gone more than (say) 10mSec since the last call, and if so, set a flag to trigger whatever you want your slave code to do.
However (of course) recovery will be dependant on the PC end triggering the reconnect as you have already achieved.
Best Wishes |
|
![](templates/subSilver/images/spacer.gif) |
|