4550 USB disconnect software but still physical connection

[betito131904]

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

[Ttelmah]

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

[Darren Rook]

[betito131904]

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?

[Tom-H-PIC]

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

[betito131904]

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 !!

[betito131904]

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.

[FvM]

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.

[betito131904]

FvM, you have a good idea!!!!

I will try to check the SOF interrupt.
_________________
Roberto

[Ttelmah]

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