 |
 |
| View previous topic :: View next topic |
| Author |
Message |
object01
Joined: 13 May 2004
Posts: 90
Location: Nashville, TN
|
| CCS USB drivers producing empty packets? |
 Posted: Tue Aug 10, 2004 6:27 pm |
 |
|
I'm having a devil of a time solving a strange USB problem. Here's the scenario: I'm using a PIC16C745 as the device's USB controller, and the 16C745 is tied to a peripheral (an 18F252) that transmits about 70KB of data to the 16C745, who is then supposed to forward that data to the PC host. Basically, the 16C745 acts as a simple relay. The peripheral PIC transmits a series of bytes over hardware UART, and the USB PIC accumulates these bytes in a time-tested cyclic buffer. The USB PIC's main() loop pulls characters from the buffer and passes each one to the following function, which is designed to simply fill a packet then ship the packet. (The flush parameter is only true when the USB PIC can't find any more characters coming over the UART; the PIC then enters a do-not-transmit state.)
| Code: | void send_USB_byte(USBAtomType output, int1 flush) {
int1 putPacketSuccess = 0;
static unsigned int8 USB_byte_count = 0;
// If not flushing, add the passed char to the outgoing buffer.
if (!flush) {
USB_packet_out[USB_byte_count++] = output;
}
// If packet is full, or instructed to flush, send the packet
if ((USB_byte_count == USB_PACKET_SIZE) || flush) {
// Do nothing on flush if buffer is empty.
if (USB_byte_count == 0) {
return;
} else {
// Wiggle attention line to peripheral to tell it to WAIT.
// usb_put_packet() disables interrupts, and that results in lost characters from the peripheral.
output_high (ATTENTION_OUT); // Request pause in data
delay_ms (20); // Allow the interrupt time to collect all characters from the hardware buffer
// Otherwise flush the packet.
do {
putPacketSuccess = usb_put_packet(EP1, USB_packet_out, sizeof(USB_packet_out), TOGGLE);
} while (!putPacketSuccess);
// Wiggle attention line to peripheral to tell it to GO
output_low (ATTENTION_OUT); // Resume data flow
// Reset for next round
USB_byte_count = 0;
// Blank the packet buffer with 0x42. Null packets do not show 0x42!
memset(&USB_packet_out[0], 0x42, sizeof(USB_packet_out));
}
}
} |
I've written a VB.NET app to talk to this device. The VB app captures the 70KB stream from the device and writes it to a file.
What we're observing is that more often than not the file will have valid data replaced with "null packets" -- packets of 0x00. These packets always replace data; they are never inserted and data is never missing without this null packet being in its place. The null packets are never in the same place. They always consist of 8 0's, and always occur on packet boundaries. We have never seen more than two of these null packets in a 70KB file, and occasionally we can get the entire stream without one, but that's rare.
I have absolutely wracked my brain trying to find the cause. At first I thought the application was screwy, but I've confirmed today that the API call to ReadFile is in fact returning 8 bytes of 0. I can't imagine how it could be the peripheral PIC, seeing as how these null packets always consist of 8 bytes, always occur on packet boundaries, and the peripheral PIC only throws bytes out the UART without regard for their grouping. Now I'm beginning to think it's somewhere in CCS's USB drivers. I'm completely out of ideas. I'm praying that somebody out there has some insight into what might be causing this problem. I'll be happy to answer any questions anybody has.
--
Jeff S. |
|
 |
bdavis
Joined: 31 May 2004
Posts: 86
Location: Colorado Springs, CO
|
|
| Posted: Tue Aug 10, 2004 9:41 pm |
|
|
I would put in some small fragments of test code between each interface such as:
if (data == 0)
{
DataZeroCnt++;
if (DataZeroCnt > DataZeroMax)
{
DataZeroMax = DataZeroCnt;
}
}
else
{
DataZeroCnt = 0;
}
I would think that this may allow you to find where the zero packets are getting generated by looking at the max number of successive zeros found on input and on output of each interface. |
|
|
object01
Joined: 13 May 2004
Posts: 90
Location: Nashville, TN
|
|
| Posted: Wed Aug 11, 2004 7:27 am |
|
|
The location of the bad packets changes every time. Not only that, but without being able to debug the 16C745, what can I do with that information even if I get it?
--
Jeff S. |
|
|
bdavis
Joined: 31 May 2004
Posts: 86
Location: Colorado Springs, CO
|
|
| Posted: Wed Aug 11, 2004 1:16 pm |
|
|
| It sounds like you have a few different sources that could be sending/receiving/ or inserting zero's - PIC18XXX, PIC16CXX, your PC. Just thought that it would be worth checking that the USB PIC is the culprit. Not sure if you can put some type of USB analyser to see if the empty packets are indeed sent by the PIC, and not being inserted by the USB drivers/software on your PC. |
|
|
|
|
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
