USB host shield debug ACM freeze

I am using a barcode scanner in RS232 emulation mode with the USB host shield and the version 2 library. It generally works, but will stop responding periodically and require unplugging and re-plugging the scanner to get it working again. I enabled debugging in the settings.h file with define ENABLE_UHS_DEBUGGING 1. I think it is telling me what is wrong, but I don’t know how to interpret the message :o . To simplify debugging, I am using the ACM terminal example from the library with no changes except enabling debugging as I mentioned. After varying number of scans, I get a message of “Ret: 0E” or Ret: 07" or Ret: 08" and the terminal stops responding until I restart the scanner by unplugging it. I don’t know which routine is returning the error message or how to interpret it. I’m using a MEGA 2560 and an Ethernet shield with the SS line reconfigured to D8 so it doesn’t step on the USB host at D10. Thinking it may be a timer issue, I tried different lc.dwDTERate baud rates between 9600 and 115200 with no improvement. I did a hardware modification to the host shield to correct a 3.3V / 5V problem that allows it to work on the shared SPI bus. Here’s the code, but again, it is just the acm_terminal example.

#include <cdcacm.h>
#include <usbhub.h>

#include "pgmstrings.h"

// Satisfy the IDE, which needs to see the include statment in the ino too.
#ifdef dobogusinclude
#include <spi4teensy3.h>
#include <SPI.h>

class ACMAsyncOper : public CDCAsyncOper
    uint8_t OnInit(ACM *pacm);

uint8_t ACMAsyncOper::OnInit(ACM *pacm)
    uint8_t rcode;
    // Set DTR = 1 RTS=1
    rcode = pacm->SetControlLineState(3);

    if (rcode)
        ErrorMessage<uint8_t>(PSTR("SetControlLineState"), rcode);
        return rcode;

    lc.dwDTERate	= 115200;
    lc.bCharFormat	= 0;
    lc.bParityType	= 0;
    lc.bDataBits	= 8;

    rcode = pacm->SetLineCoding(&lc);

    if (rcode)
        ErrorMessage<uint8_t>(PSTR("SetLineCoding"), rcode);

    return rcode;

USB     Usb;
//USBHub     Hub(&Usb);
ACMAsyncOper  AsyncOper;
ACM           Acm(&Usb, &AsyncOper);

void setup()
  Serial.begin( 115200 );
#if !defined(__MIPSEL__)
  while (!Serial); // Wait for serial port to connect - used on Leonardo, Teensy and other boards with built-in USB CDC serial connection

  if (Usb.Init() == -1)
      Serial.println("OSCOKIRQ failed to assert");

  delay( 200 );

void loop()

    if( Acm.isReady()) {
       uint8_t rcode;

       /* reading the keyboard */
       if(Serial.available()) {
         uint8_t data=;
         /* sending to the phone */
         rcode = Acm.SndData(1, &data);
         if (rcode)
            ErrorMessage<uint8_t>(PSTR("SndData"), rcode);


        /* reading the phone */
        /* buffer size must be greater or equal to max.packet size */
        /* it it set to 64 (largest possible max.packet size) here, can be tuned down
        for particular endpoint */
        uint8_t  buf[64];
        uint16_t rcvd = 64;
        rcode = Acm.RcvData(&rcvd, buf);
         if (rcode && rcode != hrNAK)
            ErrorMessage<uint8_t>(PSTR("Ret"), rcode);

            if( rcvd ) { //more than zero bytes received
              for(uint16_t i=0; i < rcvd; i++ ) {
                Serial.print((char)buf[i]); //printing on the screen
    }//if( Usb.getUsbTaskState() == USB_STATE_RUNNING..

...oh, and I should add that I really want to fix the core problem, but would appreciate it if someone could tell me what to look for to capture the "Ret: xx" in my program so I know something has gone wrong. Since it is going from another chunk of code directly to my serial monitor, I don't know what to look for in my own code.

After scanning my entire system(s) for "Res:" and finding nothing, I dug further. I discovered that the message was actually coming across the ACM connection and, implicitly, from the scanner itself. I never found documentation on the error (Honeywell), but some work with handshaking solved it and confirmed that it was not a problem with the code or host shield.

On further consideration, I wonder if the handshaking had become troublesome due to COVID 19. Hmmmm.