PIC18F24K50 USB

[georpo]

Greetings!

I want to send data from pic to PC visual basic app.
I already used CDC transfer to send 64 byte packets which works but it freezes occasionally.
Strange thing is that even though data flow is stopped, the PC-PIC usb connection is not lost. I know this because I use this:

[Ttelmah]

CDC can be fully reliable.
CDC uses bulk transfers already. Line changes (things like DTR/DSR), use isochronous transfers to give quick responses, but the data itself uses bulk.

Things that cause problems:
1) Windows itself. What version are you running?. There was a problem with the Windows CDC driver for many years which led to the belief that it was unreliable.... This was fixed in W10.
2) Cabling. USB can be upset by interference. It is also a high frequency interface, and requires careful board design, to avoid timing and mismatch problems. These are often overlooked, and then the interface is seen as unreliable.
3) There are a lot of things at the PC end that can cause problems. The first is 'USB selective suspend'. Turn this off on the port. This is designed for laptops to conserve power, with Windows sending requests to shut down individual devices. Unfortunately the power management doesn't really understand devices that are continuously sending/receiving data, and may try to suspend things that are actually working. Can cause a lot of problems.
It is possible to write the CCS application to correctly handle the suspend and re-connect, but it is quite complex.
4) The next one is some specific 'driver' programs. Systems like HP, have their own 'utility' programs, meant to make your system 'user friendly' (read this as breaking the system for most users), that do things like create system backups, with priorities above the normal running code. result they can cause problems.
5) Things like screensavers, can bottleneck the PC sufficiently that it runs out of time to handle the transfers. Just switch off the screen rather than having images displayed. I've seen fast links from a PIC that lose data when a screensaver kick in!....
6) Chipsets. Some PC chipset drivers do have nasty glitches. Particularly a couple of the Intel chipsets (where the Intel drivers are normally fine, but Windows insists on loading it's own drivers that have problems...).
7) Time. USB bulk transfers _may be delayed_ if the bus is busy. They use the time 'left over' after other things have happened. Isochronous transfer 'guarantee' to be serviced (which would explain your DTE request getting through), but only guarantee one packet on each transfer. Bulk can use all the available time not otherwise being used. Set up something like Wireshark and see just how busy your bus really is.

[georpo]

Dear Ttelmah,

Thanks for the big answer
OS=windows 7
I have used a "good quality" short USB cable.
I will try turning off USB selective suspend but the freezing may occur in 1 minute or after 20 minutes.

I do not understand what you mean specific 'driver' programs...
Is there a cdc driver that could work better ?

There are not screensavers and of course I cannot change chipset

So, what is the solution for reliable CDC operation on windows 7 ?

My USBTASK is as follows:

[Ttelmah]

Any chance you could upgrade to W10?.

Microsoft have now provided the later usbser.sys, for W8.1, but not for W7.

Try your program on a friends machine with W10. If the problem disappears you at least know 'why' you have problems.

On the driver programs, HP have their own 'utilities' that try to do jobs for you in the background. These are resource 'hogs', and cause problems for a lot of things. They are not alone in this, but theirs are about the worst.

I'd suspect that you may have an electrical noise problem on the USB bus.
In W7 usbser.sys, there is no error recovery for a bulk endpoint is a transfer fails. It just sits 'stalled' and doesn't retry. In W10 it retries. The commonest cause for such a failure is some electrical noise on the USB bus. Since it is only the one endpoint, the isochronous endpoint used for DTR etc., will still work.

[temtronic]

W10 may not be the answer.This machine has it and it will NOT 'wakeup' by moving the mouse have to 'press any key' to awaken the beast.
My 'PIC PC' has XP on it.runs fine 24/7,has for years.

If you can switch from VB to Delphi,you'll get code that's 'free from Windows'. Delphi is 'stand alone, doesn't need anything from Win and tranportable from PC to PC.
Try using a 'terminal program' and see if it 'hangs'. If it doesn't then 'something' in VB may be causing your problem.
You also may NOT be able to upgrade from W7 to W10, depending on the PC hardware. I KNOW W10 will NOT install on my XP PC.It complains about the hardware...then again, it is 15 years old.


If possible, use a separate PC for 'PIC' use. No internet, no other programs just the CCS compiler, terminal program, etc. Active virus scanner is not needed( not connected !),also disable any/all 'auto update' features. I had one program mysteriously change the power setting on a USB port 3-4 years ago, caused me no end of grief. Never ,ever did find out which one did that...USBView showed me the change though.

The core of the problem is that USB is a huge ,multi layered kludge of code and sillicon. Give me a PC with REAL RS-232 comports any day. Those never ever failed.

Jay

[georpo]

The problem appears also with hyperterminal and with realterm...
I will try in a friend's w10 pc.
I will also have a look at Delphi. I do not even know what it is...
_________________
George.

[Ttelmah]

XP didn't have the problem.

It appeared in Vista, stayed through W7, W8, and 8.1. Was then fixed in W10, with the fix being retrospectively applied in a service pack for 8.1.
FTDI did their own fix for their chipsets in W7. One of the few companies who did.

It may be he has another problem, but W7, has a known 'issue' with this...

Basically the USB hardware reports the error, but Windows ignores it.

[georpo]

I made some progress.

After freezing, I close the port from the VB app, usb_detach from the PIC side and then re-open the port from VB and everything continues to operate!

Something also strange is that even though the PIC->PC data flow freezes, I can still send data from PC->PIC. I modified the code and I send ascii 'A' from VB to PIC and then display this to real RS232 port on hyperterminal which still works even though PIC->PC stopped.

Now I can send a command to the PIC to usb_detach and possibly work around the problem. But in any case, it does not operate properly.

I still have to test on windows 10 though.

Thanks for all the kind support and time.
_________________
George.

[Ttelmah]

Yes. Key is in this from the quote above:
"bulk IN pipe".

It is the input 'pipe' on the PC that gets hung.

It does imply that you are getting quite frequent hardware errors on the USB, that must be more than just little spikes. They need to be 'burst' errors lasting for two retries to cause this to happen.
If your USB connections do not earth the cable shield, worth considering doing this.

[georpo]

From PIC side it is just a pcboard on the bench. NO ground from the power supply. But it is connected through the USB cable to the grounded PC.
_________________
George.

[Ttelmah]

[georpo]

Yes you are right but both pin 4 and mounting pins of the pcb usb plug are soldered together to the pcb ground plane.
_________________
George.

[Ttelmah]

Do you have something nearby that might be causing significant EMI?.
I read it that the PIC has an isolated 'wall wart' type supply?. You have to realise that you don't actually have a 'ground', but are dependent on the grounding all being done up the USB connection.
How long is the USB connection?.

Though these people are trying to sell you their isolators and connectors, the 'commandments' cover very real problems....

<http://www.bb-elec.com/Learning-Center/All-White-Papers/USB/The-Ten-Commandments-of-USB.aspx>

There is also a very significant variation in USB cable quality between types.
USB was designed for short local connections, for 'domestic' applications. It is being pushed when you move into anything at all industrial, beyond what it was designed to do. To get it reliable, requires you to think and start applying some careful design...

[georpo]

The PIC pcb is on my workbench.
Indeed the power supply is not grounded but what if it was a battery operated device? I will ground it and see...
USB cable is 1.5m long.
Before doing anything else I will test on windows 10 tomorrow on a friend's laptop.
_________________
George.

[Ttelmah]

The question is what is near your workbench?.
Look for USB cables that say they are 'double shielded'.
How is the actual connection made to the PIC?. How long is this?. Are the D+ and D- connections the same length?. How is the PCB laid out?.
Another thing that can cause repeated errors, is a poor signal match at the PCB. Results in ringing on the bus.