Teensy++ 2.0 Faulty USB Chip? Receiving mangled Raw HID packets

Status
Not open for further replies.

Grey

Member
I am using a Teensy++ 2.0 for USB Raw HID communication. Nothing is connected to the Teensy, apart from the USB.

The packets I send are received incorrectly - the first byte is correct, then all the remaining 63 (or less, if configured, tested that too) are filled with the second byte.

For example, if I send "ABCDEF", the Teensy receives it as "ABBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB...". I've made sure that the issue is in the Teensy reading it, not echoing it but using the built in LED as some patience.

This occurs only on one of the Teensy++ 2.0s I have access to. It has become more of a curiosity now, as it seems to be a faulty board. I am looking for some confirmation and perhaps some insight into why this happens.

Here is the minimum code:
Code:
void setup() {}

char hidBufferIn[64];
void loop() {
  int received = RawHID.recv(hidBufferIn, 20);
  if(received > 0){
      RawHID.send(hidBufferIn, 50);
  }
  delay(1000);
}

For sending the HID requests, I've used Node, and also Device Monitoring Studio. Same results for both of them, so the PC side is not at fault (and as mentioned before, only one teensy affected).

So it does seem to be faulty USB chip or something, buuuuuuuuuuuut....

The fun part is, that Serial communication works fine. And since the Teensy++ 2.0 uses USB for Serial, why does Serial communication work fine? Why would only raw HID have this problem?

Minimum code for Serial:
Code:
void setup() {
  Serial.begin(9600);
}

char inc;
void loop() {
  // put your main code here, to run repeatedly:
  if (Serial.available() > 0) {
    inc = Serial.read();
    Serial.print("USB received: ");
    Serial.println(inc);
  }
}
 
So it does seem to be faulty USB chip or something,

The USB protocol uses CRC checks on the packets. If data is corrupted, Teensy USB hardware is supposed to detect the CRC error and not reply with an ACK token. Then your PC's host controller automatically retries the transfer.

A hardware failure affecting only the CRC checking but not the rest of the USB is extremely unlikely.


The fun part is, that Serial communication works fine. And since the Teensy++ 2.0 uses USB for Serial, why does Serial communication work fine? Why would only raw HID have this problem?

USB serial also uses the same CRC checks on its data packets. I know these sorts of problems are frustrating and it's quick and easy to believe hardware must have failed, but the facts here just don't add up to such an extremely unlikely hardware issue.

The problem is very likely a software bug, maybe in the PC-side code transmitting the data?
 
Thanks for your answer!

The USB protocol uses CRC checks on the packets. If data is corrupted, Teensy USB hardware is supposed to detect the CRC error and not reply with an ACK token. Then your PC's host controller automatically retries the transfer.

A hardware failure affecting only the CRC checking but not the rest of the USB is extremely unlikely.

This Teensy is from a larger project, with over a hundred not having this issue. How come rest of the teensies are not affected?

Could mishandling the Teensy be an issue? It had most of the easily accessible pins used as buttons or LEDs, using a terminal block, without soldering. I had them removed, to minimize the problem area.

USB serial also uses the same CRC checks on its data packets. I know these sorts of problems are frustrating and it's quick and easy to believe hardware must have failed, but the facts here just don't add up to such an extremely unlikely hardware issue.

The problem is very likely a software bug, maybe in the PC-side code transmitting the data?

I've tried one written by myself, as well as a commercial one (Device Monitor Studio trial), with both I was able to reproduce the issue. I'll look for more options to test this on. Good to know it is unlikely a hardware issue, but having only one teensy facing this is weird.

This is fun to debug (no sarcasm).
 
I've decided it is a hardware issue, as no other Teensy I have access to has the same issue under the same conidtions.
 
each usb has it's own registey entry in windows. just because 1.... maybe 100 work, and 1 doesn't may or may not be hardware, but it could be a corrupted registry entry for that specific device in windows. Try to reprogram and use teensy from another computer as a test.
 
Status
Not open for further replies.
Back
Top