CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug reports on this forum. Send them to CCS Technical Support

PIC18F24K50 USB
Goto page 1, 2  Next
 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
georpo



Joined: 18 Nov 2008
Posts: 281
Location: Athens, Greece.

View user's profile Send private message

PIC18F24K50 USB
PostPosted: Fri Nov 17, 2017 1:28 am     Reply with quote

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:
Code:

if (usb_cdc_carrier.dte_present){
     Green=1;  //Turn on LED
{
else{
          Green=0; //Turn off LED
}

And when I open/close the usb serial port from the vb app, the LED on the PIC turns on and off.

After freezing, I have to unplug, and re plug the USB cable.

Code:

#fuses NOWDT,NOBROWNOUT,MCLR,CPUDIV2,PLLEN,PLL4X,HSH,PRIMARY,NOIESO,NOFCMEN //12Mhz crystal, 48MHz USB, 24Mhz clock for pic

#use delay(clock=24MHz)


I read that CDC is not supposed to send data continuously and that it will eventually fail. I really do not know.

So, is there a way to make this work reliably?

Should I prefer bulk transfer?

And then... how to write bulk transfer code for VB? Confused

Thanks in advance.
_________________
George.
Ttelmah



Joined: 11 Mar 2010
Posts: 19561

View user's profile Send private message

PostPosted: Fri Nov 17, 2017 2:26 am     Reply with quote

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



Joined: 18 Nov 2008
Posts: 281
Location: Athens, Greece.

View user's profile Send private message

PostPosted: Fri Nov 17, 2017 2:56 am     Reply with quote

Dear Ttelmah,

Thanks for the big answer Smile
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 Laughing

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

My USBTASK is as follows:
Code:

void USBTask(){
   int d=0;
         
    usb_task();
    
    if (usb_enumerated()){
     if (usb_cdc_carrier.dte_present){
     Green=1;   
       
      for(d=0;d<64;++d){
       if(usb_cdc_putready()>0) usb_cdc_putc(USBTXBuffer[d]);   
      }
    
    }
    else Green=0;
   }
}

_________________
George.
Ttelmah



Joined: 11 Mar 2010
Posts: 19561

View user's profile Send private message

PostPosted: Fri Nov 17, 2017 5:41 am     Reply with quote

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



Joined: 01 Jul 2010
Posts: 9253
Location: Greensville,Ontario

View user's profile Send private message

PostPosted: Fri Nov 17, 2017 6:11 am     Reply with quote

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



Joined: 18 Nov 2008
Posts: 281
Location: Athens, Greece.

View user's profile Send private message

PostPosted: Fri Nov 17, 2017 7:10 am     Reply with quote

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



Joined: 11 Mar 2010
Posts: 19561

View user's profile Send private message

PostPosted: Fri Nov 17, 2017 8:22 am     Reply with quote

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.

Quote:

USB hardware has built-in ability of error detection and retry. Even if a transaction is disturbed by short noise on the bus, the hardware repeats the same transaction(s), up to twice more. However, burst noise on the bus may defeat all of these retries. In such case, PC class driver is notified of the error by the host host controller, and, usually, class driver should recover the error.

Unfortunately, Windows CDC driver (usbser.sys) does no error recovery for the bulk IN pipe. It just stops the pipe. Moreover, no error is reported to the PC application.


Can your PIC device 'know' when something is wrong?. If (for instance) you acknowledge every nn packets, then the PIC can know that the connection has gone wrong.
In this can it can issue a usb_detach.
This will trigger the PC application to have an error, and it can then shut the port and re-open it.

This has been a know issue for a long time.
However I have to say that it does imply you are seeing some major error on the USB bus rather often
georpo



Joined: 18 Nov 2008
Posts: 281
Location: Athens, Greece.

View user's profile Send private message

PostPosted: Fri Nov 17, 2017 9:53 am     Reply with quote

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



Joined: 11 Mar 2010
Posts: 19561

View user's profile Send private message

PostPosted: Fri Nov 17, 2017 12:00 pm     Reply with quote

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



Joined: 18 Nov 2008
Posts: 281
Location: Athens, Greece.

View user's profile Send private message

PostPosted: Fri Nov 17, 2017 12:47 pm     Reply with quote

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



Joined: 11 Mar 2010
Posts: 19561

View user's profile Send private message

PostPosted: Fri Nov 17, 2017 12:52 pm     Reply with quote

georpo wrote:
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.


The USB cable has two grounds. The signal ground on pin 4 of the connector, but also a shield on the casing of the connector. This must connect to the lowest impedance ground point on your board.
If you are not grounding the shield, it's no wonder your signalling has problems.
georpo



Joined: 18 Nov 2008
Posts: 281
Location: Athens, Greece.

View user's profile Send private message

PostPosted: Fri Nov 17, 2017 1:05 pm     Reply with quote

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



Joined: 11 Mar 2010
Posts: 19561

View user's profile Send private message

PostPosted: Sat Nov 18, 2017 2:01 am     Reply with quote

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



Joined: 18 Nov 2008
Posts: 281
Location: Athens, Greece.

View user's profile Send private message

PostPosted: Sat Nov 18, 2017 5:36 am     Reply with quote

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



Joined: 11 Mar 2010
Posts: 19561

View user's profile Send private message

PostPosted: Sat Nov 18, 2017 5:52 am     Reply with quote

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.
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Goto page 1, 2  Next
Page 1 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group