Reset behavior - OK on Windows, not on Linux

Status
Not open for further replies.
J

jonr

Well-known member
We have a custom PCB using a MK20 and the teensy MKL04 boot loader chip. Works fine on Windows. On Linux, the virtual serial port is seen until the program button is pressed - then the serial port is gone and doesn't reappear. lsusb shows that the device is there, but no /dev/ttyACM0. Same program on both.

Any thoughts on a solution or how to debug? Perhaps some timing issue?
 
Last edited:
On Linux, run "tail -f /var/log/syslog" in a terminal.

Sometimes this will reveal kernel messages with useful info about what's really happening.
 
We tried dmesg and lsusb. Looks like programming isn't occurring. Ie, linux receives virtual serial data from existing MK20 firmware but can't program new firmware (almost like there is only one way communication).

Verbose output from the teensy loader shows it stuck doing:

02:27:04 PM: status data sent
02:27:04 PM: remote cmd: "status"
<repeats>
 
Last edited:
Does /dev/ttyACM1 appear instead?
The log from the Linux kernel regarding your device is probably more interesting than the log from the downloader program.
 
Maybe Windows and Linux are using different USB speeds. Is there a way to force Linux to the slowest speed?
 
Here's the output from syslog as Paul suggested. You can see in the first set, when the device is plugged in without programming or restarting, teensy is detected correctly. After pressing program button, it no longer detects it as a Teensy.

Code: 
Feb 11 17:23:04 greg-Gazelle-Pro avahi-daemon[735]: message repeated 8 times: [ Invalid response packet from host 35.10.59.12.]
Feb 11 17:23:04 greg-Gazelle-Pro avahi-daemon[735]: Invalid response packet from host 35.8.196.251.
Feb 11 17:23:05 greg-Gazelle-Pro avahi-daemon[735]: Invalid response packet from host 35.10.59.12.
Feb 11 17:23:50 greg-Gazelle-Pro kernel: [51771.770252] usb 1-2: new full-speed USB device number 112 using xhci_hcd
Feb 11 17:23:51 greg-Gazelle-Pro kernel: [51771.899193] usb 1-2: New USB device found, idVendor=16c0, idProduct=0483
Feb 11 17:23:51 greg-Gazelle-Pro kernel: [51771.899196] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Feb 11 17:23:51 greg-Gazelle-Pro kernel: [51771.899197] usb 1-2: Product: USB Serial
Feb 11 17:23:51 greg-Gazelle-Pro kernel: [51771.899198] usb 1-2: Manufacturer: Teensyduino
Feb 11 17:23:51 greg-Gazelle-Pro kernel: [51771.899199] usb 1-2: SerialNumber: 4294967295
Feb 11 17:23:51 greg-Gazelle-Pro kernel: [51771.899652] cdc_acm 1-2:1.0: ttyACM0: USB ACM device

--> program button pressed or load program

Code: 
Feb 11 17:24:40 greg-Gazelle-Pro kernel: [51821.570883] usb 1-2: USB disconnect, device number 112
Feb 11 17:24:41 greg-Gazelle-Pro kernel: [51822.220376] usb 1-2: new full-speed USB device number 113 using xhci_hcd
Feb 11 17:24:41 greg-Gazelle-Pro kernel: [51822.348832] usb 1-2: New USB device found, idVendor=16c0, idProduct=0478
Feb 11 17:24:41 greg-Gazelle-Pro kernel: [51822.348836] usb 1-2: New USB device strings: Mfr=0, Product=0, SerialNumber=1
Feb 11 17:24:41 greg-Gazelle-Pro kernel: [51822.348838] usb 1-2: SerialNumber: FFFFFFFF
Feb 11 17:24:41 greg-Gazelle-Pro kernel: [51822.349820] hid-generic 0003:16C0:0478.0035: hidraw4: USB HID v1.11 Device [HID 16c0:0478] on usb-0000:00:14.0-
 
Looks like it's working perfectly. HID 16c0:0478 is exactly what it does in bootloader mode.

Maybe sure you're running Teensy Loader, and you have the udev rules installed.
 
Jonr that button is a programming button not a reset button
When you press it the computer sees the Teensy disconnect and a new rawHID device connect. It remains in this state until Teensy Loader programs it and the Teensy is reset.
This disconnects the rawHID and reconnects the Teensy

It's basically toggling the two chips on the Teensy board with one shared USB
 
So in normal mode Linux will create the virtual serial port but when in programming mode, Linux won't create a virtual serial port. So this part is normal. Not so normal is that Linux appears to be attempting a status request and gets no answer - so programming doesn't start. Is it possible that there is only unidirectional communication (teensy to Linux PC)?

Note that the same Linux PC can program a stock teensy OK - so I assume that the teensy loader and udev rules are OK. Windows does a status request and it succeeds and then proceeds to program new firmware - so there is some difference between Windows and Linux.
 
Last edited:
Right so just to clarify.

You can program the blink.ino on Windows as many times as you want on both your custom board and a stock Teensy.

When you try to program the blink.ino on Linux the custom board won't program ever? However it will program a stock Teensy as many times as you want?
 
Yes.

Also, Linux may be using an older version of the Arduino software and Teensy loader - Greg?
 
I'd be surprised if this is a hardware issue but you have the 33ohm in line with d+/- lines and have impedance matched them?

For the sake of download the latest teensyduino on your linux box just so we know where we're at in terms of software
 
Maybe when you say "attempting a status request" or "does a status request", perhaps you mean Arduino/Teensyduino sends a request to the Teensy to enter programming mode? Or maybe you mean something else? I really don't know. I'm guessing you know what you mean, but this language is unclear to me.
 
The former, although your know your code and messages best. The Teensy loader outputs this, repeating endlessly. On Windows and Linux with a stock teensy, it does a few of these and then proceeds after printing "Device came online".

02:27:04 PM: status data sent
02:27:04 PM: remote cmd: "status"
<repeats endlessly>

Ie, I think it is accurate to say that the problem arises when the Teensy loader cannot detect that the custom teensy is online. What could cause a custom teensy to show up with lsusb but not respond to the status request?

Yes, the USB lines are designed to be matched and have resistors. lsusb and the correct ID proves that there is some teensy->PC communication.
 
Last edited:
Looks like it's working perfectly. HID 16c0:0478 is exactly what it does in bootloader mode.

Maybe sure you're running Teensy Loader, and you have the udev rules installed.
Click to expand...

I can confirm udev rules are installed. I've used this computer extensively with teensy 3.0 and 3.1, that's why it's so perplexing.

I have the most recent version of teensyduino, and have tested on 1.0.6 as well as 1.6.7 (fresh install), same response.

In addition, we get the same response on Mac OS, which seems to indicate this is more than just my computer.

I attached a file which shows the top level traces on the board, where the d+ and d- lines run. We have the 33 ohm resistors, and Robert and Jon ran the traces as parallel and consistent as possible. We had some parts which were overlayed over top of the lines which we removed (a 10uH inductors) but that also didn't help.

View attachment 6368

Not sure if this helps, but thought I'd throw it into the mix.
 
Maybe I missed something...

Is this a case of a custom board and a PJRC-made Teensy not working? Or is it a case where a genuine Teensy works fine, but a custom made board has trouble?

Only one of those cases would merit focusing on your PC-side settings!
 
Perhaps the next step is to use Wireshark to monitor all USB traffic and/or put a logic analyzer on the SWD/JTAG lines between the monitor and the MK20. There is some difference between Windows and Linux and also between Linux with a PJRC teensy and Linux with the custom teensy.
 
Hi folks, just wanted to close those out so the mystery is solved. It's something stupid of course. I had an old version of teensyduino (1.20 rather than 1.27) which fixed it all up. Stupid me, sorry but perhaps it'll help someone else in the future. Should have checked that earlier.

Greg
 
Status
Not open for further replies.
Back
Top