CRC errors on TWR-K60F120M HS USB

[michaelbrudevol]

I'm using MQX 4.0.2 on a TWR-K60F120M, USB mass storage in device mode, with a TWR-SER2 for HS USB, compiled using IAR.

The problem I'm having is that certain packets on USB Bulk-In are giving a CRC failure.  I connected the system to a PC running linux, and all seemed well.  I combined the USB and NAND examples to create the equivalent of a flash drive.  I can run fdisk and all is well.  I then proceed to format a fat partition, and that is where I noticed problems occurring.  The moment the FAT sectors are written, I see all kinds of CRC errors and the host is continually resetting the bus.  This continues until I wipe the NAND to remove all that had been written (unplugging/plugging the USB cable don't fix it - the same data is going to be transferred).

I backed off a bit and removed NAND from the equation and forced the read command to fill the buffer with a fixed character.  I can run dd against the device node and for most characters, it works flawlessly.  However, there are some values that I can put in there that cause an invalid CRC on the Bulk-In data.  For example, if I place 512 - 0x84's in the buffer, I can see the data go out properly (I see 512 correct bytes) when analyzed with a beagle 480, but the CRC is 0x9EF6 compared to the CRC calculated by my host of 0x9E76 (for the same transfer in a bulk-out direction).  This CRC of course is invalid causing the host to not get the data.

Any ideas?

[melissa_hunter]

Hi Michael,

How have you assembled your tower stack? For using USB-HS, I recommend putting the MCU card in the top slot and the TWR-SER2 in the bottom slot on the elevators. Seems counterintuitive, because putting the cards right next to each other creates a shorter path for signals to travel. The problem is that the signals still route to all of the elevator slots which creates signal stubs on the lines. So for high speec traces placing the two boards in the end slots is actually the ideal case for signal integrity (no signal stubs).

If you aren't doing this already, try reassembling your tower as I've described. This just might resolve the errors you are seeing.

Regards,

Melissa

[michaelbrudevol]

That is actually how I have assembled my unit.  I was going to test moving the TWR-SER2 card around, but on your recommendation, I'll leave it where it is.

The strange part is that the issue always shows up as a one bit error in the CRC word.  The data itself is just fine.

[michaelbrudevol]

I did a test where I had a 64 byte packet that was all zeroes except the last 6 bytes (which I set to 0x54, 0x84, 0x84, 0x84, 0x84, 0x54).  In this test, the failure showed up as the last 0x54 becoming 0xD4.  This does make it seem like a signal integrity problem, but not sure what I could do to correct it.  I did take apart and reassemble the tower, but that did not make a difference.

[michaelbrudevol · Accepted solution]

Ok, so I took sort of the opposite of your advice and moved the TWR-SER2 module to the second level of the tower.  Seems to be working great now...  Thanks.