USB stop receiving after disconnect and reconnect cable

[Sulymarco]

Hi everybody,

Failure description:

Usb stop receiving if the cable is disconnected and reconnected to the host and the Arduino is powered also from another source, and then when the USB cable is disconnected the board is not resetted.

Setup description:

1. Win7 PC with Arduino IDE 1.8.5 and SAMD package 1.6.19.
2. Terminal Application installed on the PC.
3. Arduino Zero board with both Native USB and Programming USB connected to the PC.
   The programming port is used by the Arduino IDE and the native USB by the
   Terminal application.

4)The TestUsbZero.ino sketch is used to reproduce the failure:

// TestUSBZero.ino

uint32_t Millis;
uint32_t Time;
uint16_t Count;

void setup()
{
  SerialUSB.begin(0);
  Serial.begin(9600);
  
  Time = millis();
  Count = 0;
}

//---------------------------------------------------------------------------------------------------------
 
void loop()                                        
{                           


  
  Millis = millis();                                        // every second print out some USB registers 
  if (Millis - Time >= 1000)   
  {
    Time = Millis;  

    Serial.print("\nEP_2 EPCFG   ");  Serial.print(USB->DEVICE.DeviceEndpoint[2].EPCFG.reg, HEX);
    Serial.print("\nEP_2 INTSET  ");  Serial.print(USB->DEVICE.DeviceEndpoint[2].EPINTENSET.reg, HEX);
      
    Serial.print("\nEP_1 EPCFG   ");  Serial.print(USB->DEVICE.DeviceEndpoint[1].EPCFG.reg, HEX);
    Serial.print("\nEP_1 INTSET  ");  Serial.print(USB->DEVICE.DeviceEndpoint[1].EPINTENSET.reg, HEX);

    Serial.print("\n---------------------------------------");   
  
  
    SerialUSB.print("String from native USB ");            // and test native USB transmission
    SerialUSB.println(Count++);
  }


  while (SerialUSB.available() > 0)                         // test native USB reception
  {                                                         //
    uint8_t RxChar = SerialUSB.read();                      //
    Serial.write(RxChar);                                   //
  }                                                         //

}

Procedure description:

1. Connect the Arduino programming port and the native USB to the PC.

2. Run the Arduino Ide and load the TestUsbZero.ino.

3. Set the board to Arduino/Genuino/Zero(programming port) and the port to the COM that matches the programming port.

4. Compile and download the sketch.

5. Open the Arduino monitor.

6. Run the Terminal application and open in it the COM that matches the native USB.

   In the Terminal application the test strings sent by the native USB are printed OUT.
   In the Arduino monitor some key USB registers are printed out.
   If we type something in the Terminal this is received by the native USB and printed out in the Arduino
   monitor.

   Everything is correct.

7. Close the port in the Terminal application to prevent it to hang.

8. Disconnect and reconnect the native USB cable and reopen the matching COM in the Terminal
   application.

   In the Terminal application the test strings sent by the native USB are printed OUT.
   In the Arduino monitor some key USB registers are printed out.

   If we type something in the Terminal this is no more received by the native USB.

Failure analysis:

This behaviour is consistent with the content of the USB registers that are monitored, as the Bulk
Endpoint Out is no more enabled.
I have tracked down this behaviour to the following patch:

Don't reallocate USB buffers if already allocated

Disabling it prevent the failure to show up.

I am not enougth expert in USB and C++ to suggest a safe and clean patch to this issue.
Please can somebody find a solution?

Marco

[ctorregrosa]

Hello,

Let me tell you that I have a similar problem.

When I start my board with external power and the USB cable connected, everything works fine. Even if I close and open the serial monitor, I can receive and send commands to the board.

But if I disconnect the USB cable and connect it again, I can only receive commands, but not send.

This problem also occurs using the RTCzero library when the board goes out of from standby mode

The code I use is:

`
long msg_time = millis();
void setup(){
SerialUSB.begin(19200); // Puerto USB

//while (!SerialUSB) ; // Wait for Serial monitor to open
SerialUSB.println("Starting...");
}

void loop(){
if (SerialUSB.available()) {
SerialUSB.write(SerialUSB.read());
delay(10);
}

if (millis() > msg_time + 2000){
msg_time = millis();
SerialUSB.println("Hello World!");
}
}
`

I hope someone can help us

Thanks.

[Sulymarco]

Hi ctorregrosa,

thanks for your comment.

Which version of the SAMD package are you using?
I guess 1.6.19 or 1.6.18.

Please load the 1.6.17 release and let me know if with it your sketch works.

Regards
Marco

[ctorregrosa]

Hi Marco,

Currently I'm using the 1.6.19 release.

Following your advice and editing the library "USBCore.cpp", specifically commenting the new line 457, 458 and 459 and adding the old line 457 of the following link:

[https://github.com/arduino/ArduinoCore-samd/commit/2bb54068a2ffad535d9d908f0bdc4ec0f1d46708]

I solved the problem temporarily.

I do not know if this modification is the right one, but it works for both problems exposed in the previous post.

Thanks fo your advice.

Regards
Cristobal

[Sulymarco]

Hi Cristobal,
many thanks for your report.

I will try to dig deeper into the issue but, as I told, I am not an USB guru and so I don't know when and if I will elaborate a clean solution.

In the meantime I kindly request the developers of the patch:
Don't reallocate USB buffers if already allocated
to take into account this problem, as it is clearly related to it.

Thanks in advance.
Marco

[facchinm]

Hi @Sulymarco ,
I've been able to reproduce the issue and fixed it in #352 .
The source of bugs was that DoubleBufferedEPOutHandler constructor both configures the endpoint and allocates buffers, so calling it only once works fine just if the USB peripheral has not been deconfigured (by a disconnection, not by entering deep sleep).
If you could test the patch and report if it works for you it would be great! Thanks

[crgallac]

@facchinm 's solution on #352 resolves this issue for me.