Proper CRC16 generation and checking

[HelloitsLuke]

Good day. I'm currently working on making a USB protocol for my project. As said in the USB 2.0 specifications, data packets should be properly protected with a CRC checksum.

 

I've used a bit of online code generators for CRC16 but never really understood how to interpret the results because the USB specification only mentioned getting a certain residual to properly decode the packet.

 

I am kind of lost on what to do to get the proper CRC residual:

 

crc_testv2.v 

Here's the code I've been working with. My questions are:

How do I generate the proper checksum from the residual result? Or should the latest residual result be the CRC16 checksum I should output?

How many bytes should I be sending through my transceiver (assuming that it only sends 1 byte at a time) worth of CRC checksum?
 

 

 

[mariushm]

Read the USB 2.0 specification : https://www.usb.org/sites/default/files/usb_20_20181221.zip

There's a 6 MB pdf file there, search for "crc" in the document.

 

[PeterBocan]

what's the 'residue' or 'residual result'?  

[HelloitsLuke]

On 4/3/2019 at 11:53 PM, mariushm said:

Read the USB 2.0 specification : https://www.usb.org/sites/default/files/usb_20_20181221.zip

There's a 6 MB pdf file there, search for "crc" in the document.

 

Yeah I've been reading this. But say that I'm sending only 1 byte at a time but I have a payload of 8 bytes, how do I know the proper CRC to send? Do I invert and reverse the bit order on every byte, or do I only do it once the actual payload has been delivered?

[HelloitsLuke]

On 4/3/2019 at 11:53 PM, PeterBocan said:

what's the 'residue' or 'residual result'?  

the residual is the polynomial after the byte has been parsed through the source code provided. Although I am not sure if I should be inverting and reversing bit-order for every data byte I send, or do I just take the residual after the CRC bits have been parsed as well.

[HelloitsLuke]

I'm just trying to replicate this packet to get the same checksum. However I am not able to product it. My question is:

 

It is correct that I only use the data bytes as the CRC input, yes? If so, in what order(as is or reverse bit order)?

Same with the CRC16, do I send it lower half first then upper half next?

[mariushm]

https://dicks.home.xs4all.nl/avr/usbtiny/

 

see usbtiny-1.7.tar.gz  at the bottom

see utils/crc16.py , usbtiny/crc.S

 

see also other "bit-banging" libraries for usb on various microcontrollers

Grainuum USB - software implementation for arm m0 and other small processors

https://github.com/xobs/grainuum

v-usb usb for AVR : https://www.obdev.at/products/vusb/index.html

software usb low speed for pic16  16fusb

http://dangerousprototypes.com/blog/2012/05/08/16usb-open-source-low-speed-bit-bang-usb-interface-for-pic16fs/

https://code.google.com/archive/p/16fusb/

https://github.com/emanuelpaz/16fusb

 

https://hackaday.com/2014/03/22/bitbanging-usb-on-low-power-arms/

 

 

see usb 2.0 specification (in the link in a previous message of mine)

quoting from page 19 (47 of 650) :

 

4.5 Robustness
There are several attributes of the USB that contribute to its robustness:
• Signal integrity using differential drivers, receivers, and shielding
• CRC protection over control and data fields

 

4.5.1 Error Detection
The core bit error rate of the USB medium is expected to be close to that of a backplane and any glitches
will very likely be transient in nature. To provide protection against such transients, each packet includes
error protection fields. When data integrity is required, such as with lossless data devices, an error recovery
procedure may be invoked in hardware or software.
The protocol includes separate CRCs for control and data fields of each packet. A failed CRC is considered
to indicate a corrupted packet. The CRC gives 100% coverage on single- and double-bit errors.

 

Chapter 8 Protocol Layer (page 198 - 226 of 650 )

 

8.3.5 Cyclic Redundancy Checks
Cyclic redundancy checks (CRCs) are used to protect all non-PID fields in token and data packets. In this
context, these fields are considered to be protected fields. The PID is not included in the CRC check of a
packet containing a CRC. All CRCs are generated over their respective fields in the transmitter before bit
stuffing is performed. Similarly, CRCs are decoded in the receiver after stuffed bits have been removed.
Token and data packet CRCs provide 100% coverage for all single- and double-bit errors. A failed CRC is
considered to indicate that one or more of the protected fields is corrupted and causes the receiver to ignore
those fields and, in most cases, the entire packet.
For CRC generation and checking, the shift registers in the generator and checker are seeded with an allones
pattern. For each data bit sent or received, the high order bit of the current remainder is XORed with
the data bit and then the remainder is shifted left one bit and the low-order bit set to zero. If the result of
that XOR is one, then the remainder is XORed with the generator polynomial.
When the last bit of the checked field is sent, the CRC in the generator is inverted and sent to the checker
MSb first. When the last bit of the CRC is received by the checker and no errors have occurred, the
remainder will be equal to the polynomial residual.
A CRC error exists if the computed checksum remainder at the end of a packet reception does not match the
residual.
Bit stuffing requirements must be met for the CRC, and this includes the need to insert a zero at the end of a
CRC if the preceding six bits were all ones.
8.3.5.1 Token CRCs
A five-bit CRC field is provided for tokens and covers the ADDR and ENDP fields of IN, SETUP, and
OUT tokens or the time stamp field of an SOF token. The PING and SPLIT special tokens also include a
five-bit CRC field. The generator polynomial is:
G(X) = X5 + X2 + 1
The binary bit pattern that represents this polynomial is 00101B. If all token bits are received without error,
the five-bit residual at the receiver will be 01100B.
8.3.5.2 Data CRCs
The data CRC is a 16-bit polynomial applied over the data field of a data packet. The generating
polynomial is:
G(X) = X16 + X15 + X2 + 1
The binary bit pattern that represents this polynomial is 1000000000000101B. If all data and CRC bits are
received without error, the 16-bit residual will be 1000000000001101B.

 

... and so on and so forth ...