title: Linux on RPi debian, hidraw write() to USB device outputs a few junk characters to /dev/hidraw0 which if not cleared jam the device
body: <p>We have a set of USB devices which we monitor using a RPi. The monitoring code polls the devices using hidraw direct interface about once a second. The protocol uses 64 byte packets to send commands and receive data and all responses are 64 bytes long at most.</p>
  <p>The same scheme works fine under Windows using the Windows HID driver. On Linux however we use hidraw and find that the device interface gets jammed after a short time resulting in unsuccessful write{}s to the device.</p>
  <p>After a lot of investigation I came across a recommendation to try to follow the communication between a host and an hidraw device using this in a terminal:</p>
  <pre><code>  sudo cat /dev/hidraw0
  </code></pre>
  <p>As it turns out, running this command outputs 4-8 bytes of unreadable characters to the terminal every <code>write()</code> and unexpectedly it also clears the jam for <code>hidraw0</code>. All subsequent <code>write()</code>'s and <code>read()</code>'s to that device work flawlessly.</p>
  <p>If that device is disconnected and then reconnected the jam condition returns shortly thereafter. I have single stepped the code and verified that the &quot;junk&quot; is output during the execution of the <code>write()</code>.</p>
  <p>I tried to add <code>fsync()</code> calls before and after the <code>write()</code> in hope to clear the buffers and avoid this issue but that did not help. The code for the <code>write()</code> and subsequent <code>read()</code> is standard as follows:</p>
  <pre><code>#define USB_PACKET 64
  #define USB_WRDELAY 10 //ms
  
  FILE* fd; 
  int errno, res;
  char packet[USB_PACKET];
  fd = 0;
  
  /* Open the Device with non-blocking reads. */
  fd = open(&quot;/dev/hidraw0&quot;, O_RDWR|O_NONBLOCK);
  
  if (fd &lt; 0) {
      perror(&quot;Unable to open device&quot;);
      return 0;    // failure
  }
  memset(packet, 0x0, sizeof(packet));
  packet[0] = 0x34;   // command code - request for USB device status bytes
  fsync();
  res = write(fd, &amp;packet, sizeof(packet));
  fsync();
  if (res &lt; 0) {
      printf(&quot;Error: %d in USB write()\n&quot;, errno);
      close(fd);
      return 0;   // failure
  } else {
      usleep(1000*USB_WRDELAY );      // delay gives OS and device time to respond
      res = read(fd, &amp;packet, sizeof(packet));
      
      if (res &lt; 0) {
          printf(&quot;Error: %d in USB read()\n&quot;, errno);
          close(fd);
          return 0; // failure 
      } else {
          // good read, packet holds the response data
          // process the device data
          close(fd); 
          return 1; // OK
      }
   }  
   return 0; // failure
     
  </code></pre>
  <p>This is a sample of the gibberish we read on the terminal running the <code>cat</code> command for each executed <code>write()</code>:</p>
  <pre><code>    4n��@/5 �
  </code></pre>
  <p>I am not understanding where this junk comes from and how to get rid of it. I tried several things that did not work out such as adding a <code>read()</code> with a timeout before the write - hoping it is some data left from a previous incomplete <code>read()</code>.</p>
  <p>Also tried to write a smaller buffer as I need only send only a 2 byte command as well as adding a delay between the <code>open()</code> and <code>write()</code>.</p>
  <p>Unfortunately using the cat in the terminal interferes with the hot plug/unplug detection of the USB devices so it is not a solution we can use in deployment.</p>
  <p>I'll appreciate any words of wisdom on this.</p>