WIO Tracker no USB (bricked?)

I was testing a WIO tracker using simple examples and it worked. Later while uploading a sketch the USB port disappeared. No reaction after unplug and replug (no log in dmesg), also on different computers.
Environment: OpenSuSE Leap, Arduino 1.8.12

The same happened with a Seeeduine Cortex-M0+.

Dear @rbehm
When you connect your WIO tracker or seeeduine Cortex-M0 +, first check whether you have successfully installed the driver, then replace the data line test, which may be the problem of the data line.

Linux does not need a driver. The USB port is automatically recognized.
It even worked before it failed. Nothing else connected, So no ESD or similar to be expected.
It worked, I tested some sketches but then it failed while downloading some modifications.
When I connected it first the port ttyACM0 was created. After the failure there is no indication that the OS sees anything at the port. No message in dmesg about a connected USB device.
The USB port on the PC is working and usable with other equipment. Testing with another PC shows the same problem.

Try changing your USB cable,…

Already done of course. And the cable works with other devices.Since this happened during download of a compiled sketch, is it possible that this function kills the boot loader including the USB config. I am suspecting this because both failed units (WIO tracker and Seeeduino Cortex-M0+) are based on the same CPU. Maybe there is a problem with the cooperation between the IDE and the plugins for this CPU type.

I’m getting the same results. I downloaded a sketch and at the end, ttyACM0 disappeared. I have second Wio Terminal and the same thing happened. I have not been able to get it back.

I do the quick double reset and I get the Arduino drive back (Linux Ubuntu 20.04 OS). So I don’t think it is totally bricked.

I tried the factory reset - Hold button 1 and reset procedure.

After compiling, it says “Sketch uses 278032 bytes (54%) of program storage space. Maximum is 507904 bytes.” So I don’t think it should have overwritten anything.

Thoughts?

I had problems on Linux (SuSE) that the “modemmanager” interfered and grabbed the serial port after it reappeared when the terminal was reset by the download program. I disabled the modemmanager because it was not needed at all.

Thanks. I don’t believe that is the problem. /dev/ttyACM0 will not enumerate anymore using both of the Wio Terminals I have in stock. Both reported a serial port issue just as the software download finished. After that, neither will enumerate, but as I said in my original post, the reset procedure will bring the “Arduino” drive up on Nautilus.

There are no other devices consuming the port.

Yes, I had the same problem. The device seemed to be dead. It also happened with a XIAO. Also tested on other PCs. No even an entry in dmesg. The double reset procedure brought it back to life. After I disabled the modemmanager all seems to work (mostly). I have the impression that the fact that the device is acting as two devices (serial+USB-memory drive) sometimes creates problems. I also had the download program not only complain but also get stuck and block ttyACM0. After that the device appeared as ttyACM1.
I have the impression that all that Ardiuno stuff is badly written software, trying to hide too much from the programmer. I would not release such stuff professionally. I usually do software for avionics (DO-178). That’s another level of quality.

To bring the devices back to life, I performed the rtl720 firmware upgrade procedure found here:

After that, the devices enumerated properly. The Blink.ino example compiled and loaded properly with the blue LED flashing as expected.

I tried a previous version of my software and that loaded and executed as expected. I modified my code with one line change (as before) and this is the error that was dumped:

Sketch uses 278048 bytes (54%) of program storage space. Maximum is 507904 bytes.
Device : ATSAMD51x19
Version : v1.1 [Arduino:XYZ] Mar 12 2020 17:43:33
Address : 0x0
Pages : 1024
Page Size : 512 bytes
Total Size : 512KB
Planes : 1
Lock Regions : 32
Locked : none
Security : false
BOD : false
BOR : true
Write 278960 bytes to flash (545 pages)
[==============================] 100% (545/545 pages)
Done in 3.522 seconds
Verify 278960 bytes of flash
[==============================] 100% (545/545 pages)
Verify successful
Done in 10.889 seconds
processing.app.SerialException: Error opening serial port ‘/dev/ttyACM0’.
at processing.app.Serial.(Serial.java:152)
at processing.app.Serial.(Serial.java:82)
at processing.app.SerialMonitor$2.(SerialMonitor.java:132)
at processing.app.SerialMonitor.open(SerialMonitor.java:132)
at processing.app.AbstractMonitor.resume(AbstractMonitor.java:132)
at processing.app.Editor.resumeOrCloseSerialMonitor(Editor.java:2120)
at processing.app.Editor.access$1300(Editor.java:117)
at processing.app.Editor$UploadHandler.run(Editor.java:2089)
at java.lang.Thread.run(Thread.java:748)
Caused by: jssc.SerialPortException: Port name - /dev/ttyACM0; Method name - openPort(); Exception type - Port not found.
at jssc.SerialPort.openPort(SerialPort.java:167)
at processing.app.Serial.(Serial.java:141)
… 8 more
Error opening serial port ‘/dev/ttyACM0’.

As before, the Wio Terminal will not enumerate. Green LED is on. The blue LED is off.

Should I post my code?
Thanks.

I did a test using the example I found here:
https://raw.githubusercontent.com/lvgl/lv_arduino/master/examples/ESP32_TFT_eSPI/ESP32_TFT_eSPI.ino

I created a sketch that works and a sketch that doesn’t work. For the code that works I left it as is. For the code that doesn’t work, I put this:

lv_obj_t *label = lv_label_create(lv_scr_act(), NULL);

where it would be global.

I used this code to eliminate my code as a variable and show that I can reproduce the error. Basically, I wanted to make the lv_obj_t *label as a global. If it is inside the function, it works fine, but putting it outside the function, breaks the Wio Terminal.

For my code, I want to display a variable label using lvgl. According to this link:

Doing it the way as indicated as [turoksama] commented [on Nov 21, 2018] in that link is the way to accomplish my goal. And I have accomplished my goal.

However, as the way I’ve described it above is not the way to do that and I won’t do that again. But, since it does compile and then gives consistently bad results, I recommend a deeper dive into the mechanics and see what is going on since Wio Terminal becomes inoperative and no errors are given.