 |
 |
| View previous topic :: View next topic |
| Author |
Message |
Emmo
Joined: 02 Feb 2017
Posts: 14
|
| [solved]major bug? USB CDC stops sending Data on PIC18F25K50 |
 Posted: Thu Feb 02, 2017 10:24 am |
 |
|
Hello guys,
I've got a little big problem when using PIC18F25K50 and sending data over cdc usb. I'm using the CCS USB CDC library which seems to running well, but after a short time, the PIC is sending no more data out. Receiving data still works. I use a usb sniffer to confirm, that there is no data coming out over usb and siow.exe is not the problem.
I changed ceramic capacitor on VUSB from 1uF to 470nF to 220nF without any improvement. I also add a 1,5k to D+ and disabled the intern pullups. Still no change.
When I increase delay to 200ms data sending works for longer time but after minutes it is still stopping.
When I define USB_ISR_POLLING, I have to remove the delay, otherwise it will not enumerate. With isr polling the data is sending continuously out and all is fine.
Compiler version: 5.042
Anyone an idea?
Here is the code:
| Code: | #include <18F25K50.h>
#device ADC=10 //return 10bit adc value
#FUSES NOWDT //No Watch Dog Timer
#FUSES NOMCLR //Master Clear pin used for I/O
#FUSES NOBROWNOUT //No brownout reset
#FUSES NOIESO //Internal External Switch Over mode disabled
#FUSES NOFCMEN //Fail-safe clock monitor disabled
#FUSES STVREN //Stack full/underflow will cause reset
#use delay(internal=8MHz,USB_FULL,ACT=USB) //run at 8MHz
#use rs232(baud=115200, xmit=PIN_C6, rcv=PIN_C7, parity=N, bits=8, ERRORS)
//#define USB_EXTERNAL_PULLUPS
//#define USB_ISR_POLLING
#include <math.h>
#include <usb_cdc.h>
int8 tick=0;
#INT_TIMER2
void tick_interrupt(void) {
if (tick) --tick;
}
void main (void)
{
int8 temp_ch;
setup_timer_2(T2_DIV_BY_16,49,15);
enable_interrupts(INT_TIMER2);
enable_interrupts(GLOBAL);
usb_init();
// usb_cdc_init();
delay_us(100);
while(TRUE)
{
usb_task();
if(usb_enumerated())
{
// printf(" \n\rUSB enumerated");
if (usb_cdc_kbhit())
{
temp_ch=usb_cdc_getc();
switch (temp_ch)
{
case 'A':
case 'a':
printf(" \n\rUSB working");
break;
case 'T':
case 't':
printf(" \n\r't' pressed");
break;
}
}
if(usb_cdc_putempty()== TRUE);
{
printf(" \n\rshould send");
delay_ms(20);
usb_cdc_putc_fast('A');
}
}
if (tick==0)
{
tick=5;
output_toggle(PIN_A3);
}
}
} |
Last edited by Emmo on Tue Feb 21, 2017 5:36 am; edited 1 time in total |
|
 |
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Thu Feb 02, 2017 11:48 pm |
|
|
When I compile your program, I get this warning.
| Quote: | | >>> Warning 207 "PCH_Test.c" Line 66(38,39): Code has no effect |
It points to the line shown in bold below. You have a semi-colon at the
end of the if() statement. This means the code inside the braces will
always be executed, even if the CDC transmitter is not empty.
Remove the semi-colon and re-test your program.
| Quote: | if(usb_cdc_putempty()== TRUE);
{
printf(" \n\rshould send");
delay_ms(20);
usb_cdc_putc_fast('A');
}
|
|
|
|
Emmo
Joined: 02 Feb 2017
Posts: 14
|
|
| Posted: Fri Feb 03, 2017 1:48 am |
|
|
| PCM programmer wrote: | When I compile your program, I get this warning.
| Quote: | | >>> Warning 207 "PCH_Test.c" Line 66(38,39): Code has no effect |
It points to the line shown in bold below. You have a semi-colon at the
end of the if() statement. This means the code inside the braces will
always be executed, even if the CDC transmitter is not empty.
Remove the semi-colon and re-test your program.
| Quote: | if(usb_cdc_putempty()== TRUE);
{
printf(" \n\rshould send");
delay_ms(20);
usb_cdc_putc_fast('A');
}
|
|
sorry, I was playing around with usb_cdc_putempty() and usb_cdc_putready(). I forgot to remove ";", but it makes no difference. The problem still occurs. When it happens usb_cdc_putempty() is always FALSE and no data is send out. Maybe host/pc is not reading the buffers? |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19494
|
|
| Posted: Fri Feb 03, 2017 2:44 am |
|
|
You talk about the capacitor on Vusb. Presumably you are running the PIC at 5V?. If your PIC is running off 3.3v, then you should be using the LF version of the chip, and 3.3v, must be connected to the Vusb3.3 pin. How close is the capacitor to the chip?. It needs to be close. Have you read section 2.4.1?. Does your capacitor have the higher voltage specification suggested?.
There are lots of 'little things' about the code that are not quite right, but they shouldn't cause transmission to stop. Realistically, it is a little silly to use the putempty test and then use putc_fast. You might as well just use the standard putc, if you you know the buffer has space.
One thing though there is a major fault in your test for putempty. Look at the line _carefully_.
What are you actually using to receive the data?. Though I'd expect it to cause problems earlier, as written you can be sending data when the port is not actually 'open'. Being enumerated, does _not_ mean there is a program at the other end ready to take the data. This is actually tested by usb_cdc_carrier.
| Code: |
{
int1 carrier=FALSE;
int8 temp_ch;
setup_timer_2(T2_DIV_BY_16,49,15);
enable_interrupts(INT_TIMER2);
enable_interrupts(GLOBAL);
usb_init_cs();
delay_us(100);
//master loop
while(TRUE)
{
usb_task();
if(usb_attached())
{
//now plug is attached and feeding power
if (usb_enumerated())
{
//Now a master has enumerated the bus
if (usb_cdc_carrier.dte_present)
{
//Now code is present at the other end
if (carrier==FALSE)
{
//send a message to the PC to say we are here
printf(usb_cdc_putc,"USB Online`=\n\r");
carrier=TRUE;
}
if (usb_cdc_kbhit())
{
temp_ch=usb_cdc_getc();
switch (temp_ch)
{
case 'A':
case 'a':
printf(" \n\rUSB working");
break;
case 'T':
case 't':
printf(" \n\r't' pressed");
break;
}
}
if (tick==0)
{
if(usb_cdc_putempty()) //look carefully
{
printf(" \n\rshould send");
usb_cdc_putc('A');
//using the tick to trigger the send
}
tick=5;
output_toggle(PIN_A3);
} //end of 'tick'
} //end of 'carrier'
else
{
carrier=FALSE; //send message if re-attached
}
}//enumerated
} //attached
} //main loop
}
|
|
|
|
Emmo
Joined: 02 Feb 2017
Posts: 14
|
|
| Posted: Fri Feb 03, 2017 4:51 pm |
|
|
| Ttelmah wrote: | You talk about the capacitor on Vusb. Presumably you are running the PIC at 5V?. If your PIC is running off 3.3v, then you should be using the LF version of the chip, and 3.3v, must be connected to the Vusb3.3 pin. How close is the capacitor to the chip?. It needs to be close. Have you read section 2.4.1?. Does your capacitor have the higher voltage specification suggested?.
There are lots of 'little things' about the code that are not quite right, but they shouldn't cause transmission to stop. Realistically, it is a little silly to use the putempty test and then use putc_fast. You might as well just use the standard putc, if you you know the buffer has space.
One thing though there is a major fault in your test for putempty. Look at the line _carefully_.
What are you actually using to receive the data?. Though I'd expect it to cause problems earlier, as written you can be sending data when the port is not actually 'open'. Being enumerated, does _not_ mean there is a program at the other end ready to take the data. This is actually tested by usb_cdc_carrier.
|
Yes I'm using the 5V version. The capacitor is really close to Vusb pin (1mm). Ground is also fine. I have red section 2.4.1. The 220nF and 470nF are 50V, the 1uF 16V. Today I've tested a X7R 4,7uF 35V and 10uF 25V (I know this is probably too much  ). The different caps have no effect.
Thanks for posting a professional version of my quick and dirty code. I have tested it, but the problem still occurs :-/ Can you please explain why I cannot compare putempty with TRUE? The header says putempty returns TRUE, if buffers are empty...
For receiving data, I use serial input/output monitor from ccs. I also tried Realterm, but makes no difference. The device is enumerted the hole time. I can send data from pc to pic through terminal program. After some seconds the pic stops sending 'A'. Pic still enumerated and port open and I can still send data from pc to pic.
I've done many tests today. Tried the old/new ccs usb windows driver. Tried it on another Win7 computer. Tried it on a WinXP computer. Always the same. No success.
When I look in the USB sniffer, the last data send out by the pic is a USBD_STATUS_STALL_PID 0xC0000004. Maybe I have to unstall?
I've also make a new board which uses the DIP package of 18f25k50 instead the SO package. Strangely the board with DIP package runs fine!!!!!! There is no difference in grounding, track tracing, etc. Same caps. Only other pic package. I have to say, that I'm using a socket for the DIP package. The SO pics I solder direct. Maybe my old soldering station hurts the pics! I will testing a other soldering station on monday. If it isn't the soldering station, it can only be a silicon problem. |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19494
|
|
| Posted: Sat Feb 04, 2017 2:18 am |
|
|
Of course you can compare it with TRUE. However, 'why bother'.
It returns a result that is true or false already. The compiler will almost certainly optimise the test away....
OK. The different behaviour between SM, and DIP, obviously says 'hardware somewhere'. Question now is 'where'.
Difference likely:
1) As you say soldering. However modern chips really are quite rugged.
2) Possibility of a micro whisker between legs, or flux causing more capacitance than expected.
3) Is the USB track spacing the same?. Have you looked at the USB.org recommendations on PCB layout?.
4) Double check the version numbers of the chips. I can't think of any errata's for these though. Also date codes.
5) Have you bought through a genuine supplier?. There have been cases of scrapped chips from the production line, being 're-packaged' and sold as genuine....
There are not any different USB drivers. You are always just using the Microsoft USBSER.SYS The 'drivers' are just information files to tell the OS to use this driver for the device. The older 'driver', had different VID numbers. It was using the MicroChip VID, so couldn't be 'signed' by MicroSoft. CCS paid to buy their own VID, and the later 'driver' uses this VID, and is signed, so won't complain when you try to install it on later OS's.
Which surface mount package are you using?. |
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9220
Location: Greensville,Ontario
|
|
| Posted: Sat Feb 04, 2017 6:17 am |
|
|
I'm with Mr. T about a hardware issue, probably excess flux or a itty bitty solder whisker. It has to be 'challenging' to hand solder ANY SMD device let alone a muilti pinned PIC !
In the early days when we assembled our PCB in house, we hand soldered and then tossed them into the dishwasher for cleaning. Solder had 'environmentally friendly' water based fluxes( new back then...). All boards came out clean, blown dry then tested for 24hrs. Any that failed went to repair, one of several hats I wore back then...
Jay |
|
|
Emmo
Joined: 02 Feb 2017
Posts: 14
|
|
| Posted: Mon Feb 06, 2017 2:42 am |
|
|
| Ttelmah wrote: |
Difference likely:
1) As you say soldering. However modern chips really are quite rugged.
2) Possibility of a micro whisker between legs, or flux causing more capacitance than expected.
3) Is the USB track spacing the same?. Have you looked at the USB.org recommendations on PCB layout?.
4) Double check the version numbers of the chips. I can't think of any errata's for these though. Also date codes.
5) Have you bought through a genuine supplier?. There have been cases of scrapped chips from the production line, being 're-packaged' and sold as genuine....
Which surface mount package are you using?. |
Hello,
I've tested another soldering station, but it isn't my soldering station. Still same problem.
2) I've actually four pics with this failure. I don't think, that I have solder all bad.
3) Yes it is all identically. Today I've solder the DIP package with some wires to the SO layout and the DIP is working. There is really no difference.
4) In the errata there is nothing read about USB issues.
SO version number: 14181DP
DIP version number: 1417TER
5) Yes, they are from a genuine supplier! Tomorrow I get some from another supplier. Hope they are working.
I'm using PIC18F25K50-I/SO and PIC18F25K50-I/SP. |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19494
|
|
| Posted: Mon Feb 06, 2017 5:35 am |
|
|
Have a look at this thread:
<http://www.microchip.com/forums/m448606.aspx>
The DIP version always has slightly more capacitance between the legs than the SOIC version (the internal wiring). It can make a difference. |
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Mon Feb 06, 2017 10:28 am |
|
|
Lets go over some of the things from that thread.
Do you have any floating inputs in your design ? This means pins
with (usually) no external connections that are uninitialized in your
program or are initialized as inputs.
Another common test is, put your finger on the chip. Does it then start working ? |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19494
|
|
| Posted: Mon Feb 06, 2017 12:21 pm |
|
|
Also, are both grounds connected?.
I've seen the DIP be less sensitive to only having one connected. I think they have extra bonding in the external connections. |
|
|
Emmo
Joined: 02 Feb 2017
Posts: 14
|
|
| Posted: Tue Feb 07, 2017 9:41 am |
|
|
| PCM programmer wrote: | Lets go over some of the things from that thread.
Do you have any floating inputs in your design ? This means pins
with (usually) no external connections that are uninitialized in your
program or are initialized as inputs.
Another common test is, put your finger on the chip. Does it then start working ? |
I've set all I/O pins to output low, then output high, then output floating. Always same behavoir. Not working.
I can put my finger on the chip, I can put my finger on D+ D- pin, still not working.
| Ttelmah wrote: | Also, are both grounds connected?.
I've seen the DIP be less sensitive to only having one connected. I think they have extra bonding in the external connections. |
Yes, I have connected both grounds.
Did not receive new chips from other supplier today. I hope they come tomorrow. I tell you if they work or not. |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19494
|
|
| Posted: Wed Feb 08, 2017 3:59 am |
|
|
It'll be interesting to hear.
The codes on the chips show them to have been manufactured within a week of one another, but at a different factory. There have sometimes been huge batch faults with PIC's (I had 20000, that were all faulty in one particular application...). If there was a fault though, it'd probably be 'known' by now. |
|
|
newguy
Joined: 24 Jun 2004
Posts: 1907
|
|
| Posted: Wed Feb 08, 2017 7:36 am |
|
|
| Ttelmah wrote: | | If there was a fault though, it'd probably be 'known' by now. |
Maybe not. Years ago I used a particular ESD suppression IC in a design. The first winter I started hearing from the customer about weird things happening, but only when the temperature was just below 0C. I traced the issue to the ESD IC becoming a dead short between ~-5C and 0C. I explained the issue to the manufacturer and they asked for any spare ICs I had left over. I returned the faulty chips and a few months later, when designing some other product, I noticed that there was no stock of that IC anywhere. Then I noticed that the manufacturer had removed it from their catalog. |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19494
|
|
| Posted: Wed Feb 08, 2017 9:10 am |
|
|
Agreed. That is why I said 'probably', rather than just 'would'. 
It also is often that something 'else' about the design just happens to show a problem. |
|
|
|
|
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
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
