TinyUSB Trips Port on Upload to EdgeBadge

Post here about your Arduino projects, get help - for Adafruit customers!

Moderators: adafruit_support_bill, adafruit

Please be positive and constructive with your questions and comments.
Locked
User avatar
ravensjester
 
Posts: 9
Joined: Sat Mar 18, 2017 3:59 pm

TinyUSB Trips Port on Upload to EdgeBadge

Post by ravensjester »

Background.
I’ve been working the last few weeks, trying to get an EdgeBadge running to use as the centerpiece of a class I’m supposed to teach later this month. But while I should be figuring out the curriculum, I’ve been horsing around trying to get the basic Arduino procedure going.

Hardware
- Various, but the system I’ll describe is Dell Latitude 7250
- Adafruit EdgeBadge, 350mAh LiPo, speaker (EB)

Software
- OS Windows 10 Enterprise
- Arduino IDE 1.8.9 (yes, there’s an update, but it’s don’t-mess-with-anything institutional computer, and the guy who enforces that scares me)
- Arduino, Adafruit libraries, installed per Adafruit EdgeBadge TensorFlow website.

Procedures
- Load Arduino IDE
- Plug EdgeBadge in via known-good USB cable
- EB Power on
- Check IDE>Tools>Port
o Port is grayed out
o No COM on Windows Device Manager
- Click EB Reset
o No effect detected anywhere
- Double-click EB Reset.
o IDE>Tools>Port shows “COM4 (Adafruit PyBadge M4 Express (SAMD51)”
o Windows Device Mgr now shows COM port along with LPT
- Load Blink
- Compile -> ok
- Upload
o Compiles
o Start to Upload, Port trips, vanishes everywhere
o Upload fails with message “Couldn’t find a Board on the selected port.”

This behavior is intermittent, first appearing for me about a month ago, and in that time, I’ve googled error messages, started over on installation procedures, torn out what little hair I have left.

Judging from the hundreds (thousands?) of google responses, this has been a problem for years and broken many spirits. There are hundreds of forum responses and youtube videos claiming to have found the simple procedures that fix the problem. None do. Some tell heartbreaking stories of failed projects, broken promises and despair.

I’m an old man, character calcified by harsh experience, and when I mess with something like this, I keep a record, step by step, in ink, in a bound notebook. Today, I went back over it, from the bright, enthusiastic early days through the confusion and to the despair.

I traced the onset of the Port tripping behavior to selection of TinyUSB for the USB stack in the IDE. I forget why I did it, but I’m pretty sure I came across the directive in the EB TensorFlow instructions.

Thing is, I can set the USB Stack to Arduino and load and run all the simple test programs, but, as I understand it, I’ll need TinyUSB to upload the heftier TensorFlowLite demos for the memory management. As the centerpiece of a class, the EB has to be able to run the TFL programs.

Question now is do I quit now? Can I fix TinyUSB? Can I fix whatever I’m doing wrong in my implementation?

TIA,
Fred

User avatar
adafruit_support_mike
 
Posts: 67391
Joined: Thu Feb 11, 2010 2:51 pm

Re: TinyUSB Trips Port on Upload to EdgeBadge

Post by adafruit_support_mike »

That's most likely to be the result of the USB firmware crashing. There are a few underlying issues, and what amounts to some boundary infighting.

The programming sequence runs as follows:

- The Arduino IDE opens and closes a 1200 baud Serial connection as a cue that tells the microcontroller to reboot.
- The runtime environment for your code tears down its USB connection.
- The runtime environment triggers a processor reset.
- The microcontroller's startup sequence initiates execution of the bootloader.
- The bootloader makes a USB connection to the computer.
- The bootloader uploads your firmware and writes it to user program memory.
- The bootloader tears down its USB connection.
- The bootloader transfers execution to the code in user program memory.
- The runtime environment for your firmware opens a new USB connection with the computer.
- Your code can then negotiate a USB Serial connection if it wants to.

The two independent USB connections are necessary because the bootloader and user code live in different domains of memory protection. Your code isn't allowed to see or execute any part of the bootloader's text.

There are a couple of external issues too:

The USB device recognition process involves some data transfer and configuration that takes time. To save time in the future, all major OSes record the settings for the devices they've seen, and use those the next time they see the device open a connection. Windows happens to see the bootloader's USB connection and the connection established by the runtime environment for user code as two different devices, and assigns them to different COM ports.

That's a Windows-specific issue.. MacOS and the other 'nixes open USB device files in a semi-consistent way. If you only have one USB Serial device connected, it will map to the same device file every time. If you have N USB Serial devices connected, they'll map to the same group of device files every time, but you can't guarantee that microcontroller-A will always map to device file /dev/usbS0 every time. It's more of a first-come-first-served situation.

Also, the USB-3 device recognition starts with a burst of 480MHz data that 12MHz full-speed devices should ignore. The USB signals connect to the microprocessor though, in this case a device with a 120MHz CPU clock. The high-speed data looks like unstable input, and can throw the microcontroller's USB peripheral into a state where it can't recover and keep going. That leads to a blocking condition where the microcontroller can no longer hear the USB signals that would tell it to reboot.

The pieces are distributed widely enough that there's no clear 'they should do this to fix it' that will address everything.

In most cases, putting a cheap/old USB-2 hub between the computer and the microcontroller helps. The hub can't generate the 480MHz burst, so it shouldn't make the chip hang. It won't have any effect on Windows choosing to hop from one COM port to another, but should at least make the data connections stable.

Locked
Please be positive and constructive with your questions and comments.

Return to “Arduino”