FeatherS2 USB CDC driver not working after uploading code in Arduino IDE

[cversek]

Hardware:

Board: UM FeatherS2
Core Installation version: 2.0.0-alpha1
IDE name: Arduino IDE 1.8.7
Flash Frequency: 40Mhz
Serial Connected to: USB CDC
PSRAM enabled: yes
Upload Speed: 115200
Computer OS: 5.4.0-72-generic #80-Ubuntu SMP Mon Apr 12 17:35:00 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

Description:

Use blink sketch as test of Arduino code uploading. First put device into firmware upload mode (hold BOOT button, push and release RST), serial port shows up as /dev/ttyACM0, then device can be flashed. Pushing RST is necessary to reset the board. Blink is working! However, /dev/ttyACM* is now missing :(
This the relevant dmesg output:

[ 3008.893615] usb 1-5: new full-speed USB device number 21 using xhci_hcd
[ 3009.043894] usb 1-5: New USB device found, idVendor=303a, idProduct=0002, bcdDevice= 7.23
[ 3009.043899] usb 1-5: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 3009.043903] usb 1-5: Product: ESP32-S2
[ 3009.043905] usb 1-5: Manufacturer: Espressif
[ 3009.043907] usb 1-5: SerialNumber: 0
[ 3009.046647] cdc_acm 1-5:1.0: ttyACM0: USB ACM device
[ 3019.049139] usb 1-5: USB disconnect, device number 21
[ 3019.729459] usb 1-5: new full-speed USB device number 22 using xhci_hcd
[ 3019.880020] usb 1-5: config 1 has no interfaces?
[ 3019.881358] usb 1-5: New USB device found, idVendor=239a, idProduct=80ab, bcdDevice= 1.00
[ 3019.881409] usb 1-5: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 3019.881413] usb 1-5: Product: FeatherS2
[ 3019.881416] usb 1-5: Manufacturer: Unexpected Maker
[ 3019.881418] usb 1-5: SerialNumber: 7c:df:a1:03:4e:74

Sketch:

/*
  Blink
  Turns on an LED on for one second, then off for one second, repeatedly.

  This example code is in the public domain.
 */

// Pin 13 has an LED connected on most Arduino boards.
// Pin 11 has the LED on Teensy 2.0
// Pin 6  has the LED on Teensy++ 2.0
// Pin 13 has the LED on Teensy 3.0
// give it a name:
int led = 13;

// the setup routine runs once when you press reset:
void setup() {
  // initialize the digital pin as an output.
  pinMode(led, OUTPUT);
}

// the loop routine runs over and over again forever:
void loop() {
  digitalWrite(led, HIGH);   // turn the LED on (HIGH is the voltage level)
  delay(1000);               // wait for a second
  digitalWrite(led, LOW);    // turn the LED off by making the voltage LOW
  delay(1000);               // wait for a second
}

Debug Messages:

Enable Core debug level: Debug on tools menu of Arduino IDE, then put the serial output here 

Sorry, no serial output is visible because of the issue.
Here is the Arduino terminal output:

WARNING: Category '' in library ESP RainMaker is not valid. Setting to 'Uncategorized'
WARNING: Category '' in library WiFiProv is not valid. Setting to 'Uncategorized'
Sketch uses 216706 bytes (10%) of program storage space. Maximum is 2097152 bytes.
Global variables use 13968 bytes (4%) of dynamic memory, leaving 313712 bytes for local variables. Maximum is 327680 bytes.
esptool.py v3.1-dev
Serial port /dev/ttyACM0
Connecting....
Chip is ESP32-S2
Features: WiFi, ADC and temperature sensor calibration in BLK2 of efuse
Crystal is 40MHz
MAC: 7c:df:a1:03:4e:74
Uploading stub...
Running stub...
Stub running...
Configuring flash size...
Auto-detected Flash size: 16MB
Compressed 8192 bytes to 47...
Writing at 0x0000e000... (100 %)
Wrote 8192 bytes (47 compressed) at 0x0000e000 in 0.1 seconds (effective 903.0 kbit/s)...
Hash of data verified.
Flash params set to 0x024f
Compressed 13616 bytes to 9362...
Writing at 0x00001000... (20 %)
Writing at 0x00001c33... (40 %)
Writing at 0x0000278a... (60 %)
Writing at 0x00003299... (80 %)
Writing at 0x00003e9c... (100 %)
Wrote 13616 bytes (9362 compressed) at 0x00001000 in 0.2 seconds (effective 576.3 kbit/s)...
Hash of data verified.
Compressed 216832 bytes to 122508...
Writing at 0x00010000... (1 %)
Writing at 0x00011348... (3 %)
Writing at 0x0001267c... (5 %)
Writing at 0x00014172... (6 %)
Writing at 0x00015ac8... (8 %)
Writing at 0x00016ef4... (10 %)
Writing at 0x00018718... (11 %)
Writing at 0x0001abbc... (13 %)
Writing at 0x0001c5bc... (15 %)
Writing at 0x0001d605... (16 %)
Writing at 0x0001df55... (18 %)
Writing at 0x0001e855... (20 %)
Writing at 0x0001f254... (21 %)
Writing at 0x0001fdef... (23 %)
Writing at 0x00020aba... (25 %)
Writing at 0x00021656... (26 %)
Writing at 0x00022085... (28 %)
Writing at 0x00022a33... (30 %)
Writing at 0x0002348c... (31 %)
Writing at 0x00023e05... (33 %)
Writing at 0x0002472e... (35 %)
Writing at 0x0002516f... (36 %)
Writing at 0x00025bac... (38 %)
Writing at 0x000267a4... (40 %)
Writing at 0x000271ed... (41 %)
Writing at 0x00027af5... (43 %)
Writing at 0x000285f2... (45 %)
Writing at 0x000290bc... (46 %)
Writing at 0x00029aac... (48 %)
Writing at 0x0002a48f... (50 %)
Writing at 0x0002af6b... (51 %)
Writing at 0x0002b9fb... (53 %)
Writing at 0x0002c3d7... (55 %)
Writing at 0x0002ce01... (56 %)
Writing at 0x0002d8a8... (58 %)
Writing at 0x0002e3ea... (60 %)
Writing at 0x0002ef01... (61 %)
Writing at 0x0002f9f8... (63 %)
Writing at 0x0003044c... (65 %)
Writing at 0x00030fb2... (66 %)
Writing at 0x000325a0... (68 %)
Writing at 0x0003354e... (70 %)
Writing at 0x0003475e... (71 %)
Writing at 0x00035b68... (73 %)
Writing at 0x00037eeb... (75 %)
Writing at 0x000390cf... (76 %)
Writing at 0x00039a7d... (78 %)
Writing at 0x0003a3e0... (80 %)
Writing at 0x0003cb71... (81 %)
Writing at 0x0003d5c3... (83 %)
Writing at 0x0003e018... (85 %)
Writing at 0x0003eb96... (86 %)
Writing at 0x0003f602... (88 %)
Writing at 0x00040093... (90 %)
Writing at 0x00040b41... (91 %)
Writing at 0x0004161c... (93 %)
Writing at 0x00042322... (95 %)
Writing at 0x0004301b... (96 %)
Writing at 0x00043907... (98 %)
Writing at 0x00044402... (100 %)
Wrote 216832 bytes (122508 compressed) at 0x00010000 in 1.9 seconds (effective 889.8 kbit/s)...
Hash of data verified.
Compressed 3072 bytes to 125...
Writing at 0x00008000... (100 %)
Wrote 3072 bytes (125 compressed) at 0x00008000 in 0.0 seconds (effective 659.5 kbit/s)...
Hash of data verified.

Leaving...
Hard resetting via RTS pin...
ERROR: ESP32-S2 chip was placed into download mode using GPIO0.
esptool.py can not exit the download mode over USB. To run the app, reset the chip manually.
To suppress this error, set --after option to 'no_reset'.
To suppress this error, set --after option to 'no_reset'.

[chegewara]

Did you select in menu "Serial connected to: USB CDC"?

[cversek]

@chegewara
Yes that was selected.

The device shows up with the lsusb command, but it does not set up a serial port:

Bus 001 Device 008: ID 239a:80ab Unexpected Maker FeatherS2

I will show the dmesg command output here again:

[  240.826688] usb 1-5: new full-speed USB device number 8 using xhci_hcd
[  240.977184] usb 1-5: config 1 has no interfaces?
[  240.978777] usb 1-5: New USB device found, idVendor=239a, idProduct=80ab, bcdDevice= 1.00
[  240.978783] usb 1-5: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[  240.978787] usb 1-5: Product: FeatherS2
[  240.978790] usb 1-5: Manufacturer: Unexpected Maker
[  240.978793] usb 1-5: SerialNumber: 7c:df:a1:03:4e:74

In particular the line config 1 has no interfaces? is anomalous.

[cversek]

Here is the output of lsusb -v:

Bus 001 Device 009: ID 239a:80ab Unexpected Maker FeatherS2
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass          239 Miscellaneous Device
  bDeviceSubClass         2 
  bDeviceProtocol         1 Interface Association
  bMaxPacketSize0        64
  idVendor           0x239a 
  idProduct          0x80ab 
  bcdDevice            1.00
  iManufacturer           1 Unexpected Maker
  iProduct                2 FeatherS2
  iSerial                 3 7c:df:a1:03:4e:74
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength       0x0009
    bNumInterfaces          0
    bConfigurationValue     1
    iConfiguration          4 TinyUSB Device
    bmAttributes         0xc0
      Self Powered
    MaxPower              500mA
can't get device qualifier: Resource temporarily unavailable
can't get debug descriptor: Resource temporarily unavailable
Device Status:     0x0001
  Self Powered

[cversek]

UPDATE: adding Serial.begin(); to setup "fixes" the missing port issue.

Now when running dmesg:

[ 2668.751305] usb 1-5: new full-speed USB device number 13 using xhci_hcd
[ 2668.901666] usb 1-5: New USB device found, idVendor=239a, idProduct=80ab, bcdDevice= 1.00
[ 2668.901671] usb 1-5: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 2668.901675] usb 1-5: Product: FeatherS2
[ 2668.901678] usb 1-5: Manufacturer: Unexpected Maker
[ 2668.901680] usb 1-5: SerialNumber: 7c:df:a1:03:4e:74
[ 2668.904981] cdc_acm 1-5:1.0: ttyACM0: USB ACM device

Is this a feature or a bug?
I still think this is a little bit unexpected behavior.

Here is the updated code:

Sketch:

/*
  Blink

  Turns an LED on for one second, then off for one second, repeatedly.

  Most Arduinos have an on-board LED you can control. On the UNO, MEGA and ZERO
  it is attached to digital pin 13, on MKR1000 on pin 6. LED_BUILTIN is set to
  the correct LED pin independent of which board is used.
  If you want to know what pin the on-board LED is connected to on your Arduino
  model, check the Technical Specs of your board at:
  https://www.arduino.cc/en/Main/Products

  modified 8 May 2014
  by Scott Fitzgerald
  modified 2 Sep 2016
  by Arturo Guadalupi
  modified 8 Sep 2016
  by Colby Newman

  This example code is in the public domain.

  http://www.arduino.cc/en/Tutorial/Blink
*/
#define LED_BUILTIN 13
// the setup function runs once when you press reset or power the board
void setup() {
  Serial.begin();  //FIXME this is necessary for the TinyUSB driver to export serial port interface
  // initialize digital pin LED_BUILTIN as an output.
  pinMode(LED_BUILTIN, OUTPUT);
}

// the loop function runs over and over again forever
void loop() {
  digitalWrite(LED_BUILTIN, HIGH);   // turn the LED on (HIGH is the voltage level)
  delay(1000);                       // wait for a second
  digitalWrite(LED_BUILTIN, LOW);    // turn the LED off by making the voltage LOW
  delay(1000);                       // wait for a second
}

[chegewara]

Oh, thats interesting. Descriptor is broken.

[cversek]

@chegewara
I actually first noticed this problem when trying to learn the esp-idf, but was stymied by the inability to use idf.py monitor command to see the output. If you could figure out what the equivalent "simple fix" would be there, it would be much appreciated.

[chegewara]

Something is broken and descriptor seems to be not loaded. It is very weird because USB serial example works good, and as far as i know it should be used exactly the same code.
I wanted to suggest to wrap code around USB serial example, but this is not best solution, because will let you to flash over USB without buttons, but still wont let you to use monitor logs.

@me-no-dev for some reason configuration descriptor length is only 9 bytes, and should be 75 (size of descriptor in USB serial example)

[ozgurbostan]

Dear @me-no-dev and @chegewara,

The same problem exist in Windows 10 OS with some similarities and some differences.

USB CDC upload option is not working without "Serial.begin()" initialization. The COM port enumeration remains without any change, however the port is not working.

If "Serial.begin()" is used or else the application code is wrapped by USB Serial example, USB CDC uploading is working with an exception; you have to push upload button twice. In the first run the bootloader mode is activated, and in the second the flashing is executed.

[chegewara]

Sorry for my mistake. Yes, of course you have to call Serial.begin(115200) in your code (i forgot to add it today). In that case descriptor is correctly build.

My tests with upload over USB:

• with USB serial example installed, you can flash next time on any OS
• with "Serial connected to: USB", on ubuntu you can flash, on windows also works; i tested it right now on windows 10 in VirtualBox VM; 1 time press "Upload" in arduino ide

From my point of view it is finally working fine.

[ozgurbostan]

It's weird, I have tried three different computers with Win 10 and all of them have same problem; Upload button should be pressed twice.

[UnexpectedMaker]

Seperate to the Serial.begin() discussion, after flashing the board in download mode, the FeatherS2 CDC should appear as an enumerated device in the ports list for further flashing. This seems to be broken?

@me-no-dev is this a bug or has the intended behaviour changes from what we originally spoke about and what was implemented? Right now I have to go into download mode every time I want to flash the board :(

This is confusing a lot of people, especially because I posted a video showing how it used to work and that's what folks are expecting to happen.

[me-no-dev]

@UnexpectedMaker I have not investigated on Windows, but there generally should not be an issue, because persistance is not enabled, therefore the driver should reenumerate on each reboot. One possibility is that the chip does not properly enter download mode. Could you try selecting the general ESP32S2 Dev Board?

[ozgurbostan]

Hi @me-no-dev and @UnexpectedMaker,

I have selected "ESP32S2 Dev Board" up to now while doing my tests for our own custom development board and the problems still exist in Windows 10 OS. You can read my previous post describing the problem as follows.

USB CDC upload option is not working without "Serial.begin()" initialization. The COM port enumeration remains without any change, however the port is not working.

If "Serial.begin()" is used or else the application code is wrapped by USB Serial example, USB CDC uploading is working with an exception; you have to push upload button twice. In the first run the bootloader mode is activated, and in the second the flashing is executed.

I have faced this issue all the Windows machines (at least 3-4) that I have.

[chegewara]

In my previous tests i confirmed it is working, but i read that other users have problems with it, so i decided to repeat tests.
I prepared windows 10 system again, with fresh installation and i have mixed results. It is working and it is not working.
I dont know the cause of the issue, but i was able to find reproducible test:

• it is working when i am flashing one after another, but
• when i open Serial monitor then first time flashing fail, and next is fine. (closing it does not help)
• again, flashing without opening Serial monitor is successful all the time

It seems like Serial monitor in arduino IDE is claiming port and not releasing it after closing.

[UnexpectedMaker]

@UnexpectedMaker I have not investigated on Windows, but there generally should not be an issue, because persistance is not enabled, therefore the driver should reenumerate on each reboot. One possibility is that the chip does not properly enter download mode. Could you try selecting the general ESP32S2 Dev Board?

@UnexpectedMaker I have not investigated on Windows, but there generally should not be an issue, because persistance is not enabled, therefore the driver should reenumerate on each reboot. One possibility is that the chip does not properly enter download mode. Could you try selecting the general ESP32S2 Dev Board?

I don't know what you mean by "persistence is not enabled" ? is that what you call the functionality that used to be in the beta branch where the board once flashed in Arduino IDE would use the CDC from then on and see the USB when plugged in?

Definitely not working as it used to in the beta branch - tested on Win10 and macOS.

I've opened a new issue for this to not confuse it to the serial discussion,.
#5139