Query Teensy 3.6 CRC on transmitted USB data

Status
Not open for further replies.

paqwa

Member
Hi,
Could someone please comment on whether or not the teensy usb driver in Win7/10 does a CRC check on the validity of data transmitted to/from a Teensy 3.6 via USB serial. I suspect it does not as sometimes when transferring data (typically transferring relatively small image files to/from an sd card on the Teensy 3.6) in an electrically noisy environment I find that some files are perfect while other files get corrupted. It seems to be pretty random in most of the time it works fine but sometimes you get the odd file that gets corrupted but re-sending the same file work okay. I'm getting around the problem by sending a checksum value after I send a file, checking against what was received by the Teensy 3.6 and then re-sending if they don't match. However, I'd like to try and get to the bottom of this as I also send many other custom commands via serial for which I have corresponding code on the Teensy 3.6 but don't do a checksum on all chars sent.

I'd like to implement a CRC check on all data packets sent/received, could anyone tell me if this can be done in a relatively easy manner for all data that is transferred in/out.

Any info much appreciated. Thanks.
 
Paul can answer for sure but IIRC it has been noted that the USB transfers do use standard USB protocol integrity checks.

Perhaps a packet is being missed - or not all data is making it into packets in order?
 
Yes, CRC checking is built into the USB protocol. The CRC fields are computed and verified at the hardware level, so you won't find specific code on Teensy or in the PC side drivers. It's done automatically by the hardware.

If you want to confirm this, here's a copy of the USB 2.0 spec.

https://www.pjrc.com/teensy/beta/usb20.pdf

The format of packets which carry actual data appears on page 206 (the 234th page in the PDF). As you see in the other pages of chapter 8, the small non-data packets also have CRC checks, but only 5 bits for those tiny packets rather than the full 16 bits used for data packets.

The CRC algorith, is specified in section 8.3.5 starting on page 198 (226th page of the PDF).

The one exception is the PID fields, on page 195 (223rd page of the PDF). Instead of a CRC, PIDs repeat all 4 bits with their inverted value.

The handling of errors is partially described on page 221 and elsewhere in the standard, but the finer details are spelled out in the OHCI and EHCI standards, which are not nearly as simple and easy to read & understand as the base USB spec.
 
Last edited:
Perhaps a packet is being missed

USB guards against missing packets using a data token toggling method, where data packets use alternating tokens. This is mainly documented in section 8.6 on pages 232 to 236 (starting at 260th page in the PDF).

If you look in at the code in usb_dev.c, you will see stuff about initializing and handling the data token toggle stuff, because the hardware reports the packets in different buffer descriptor table entries.
 
USB guards against missing packets using a data token toggling method, where data packets use alternating tokens. This is mainly documented in section 8.6 on pages 232 to 236 (starting at 260th page in the PDF).

If you look in at the code in usb_dev.c, you will see stuff about initializing and handling the data token toggle stuff, because the hardware reports the packets in different buffer descriptor table entries.

My reference there was to confirm the user code is properly accounting for all bytes <on both ends> … not a question to USB integrity.
 
Last edited:
Thanks very much for your prompt responses on this matter. If I understand correctly, you're both saying that all USB serial communications to the Teensy 3.6 are in fact validated between source and receiver at the hardware level. If so, the issue must be due to the way my application on PC and firmware on Teensy is sending/receiving the information. I guess this is positive but now I'm not sure where to look for the errors. The output data is simply being streamed from the PC via a Serial write command and is being read in the other end using a Serial read command. The file level checksum I implemented is very basic, just adds up the individual values of all bytes in a file to generate a 16 bit unsigned integer which rolls over as needed. The final value is sent to the Teensy 3.6 for comparison with the same simple operation conducted on the Teensy for comparison. Hence this type of simple checksum wouldn't catch bytes coming in the wrong order but only that all correct bytes were received (unless I'm very unlucky and it happens to hit the checksum with incorrect bytes!). This check is done on the data before writing to the SD card so error happens before this, also as it occurs randomally, and only in what I believe are noisy environments, it's quiet hard to replicate.

Just not too sure where to look or to experiment with different code to try and find the error in my ways!!!
 
The Teensy can overwhelm a PC with streamed data. Obviously data integrity is key - not sure about speed? At least to observe the process to work perhaps ...

Looking here https://www.pjrc.com/teensy/td_serial.html at Transmit Buffering using the Serial.send_now() will slow the sending process and may gie an idea where the issue comes in.
 
Status
Not open for further replies.
Back
Top