Forum Rule: Always post complete source code & details to reproduce any issue!
Results 1 to 20 of 20

Thread: Reset behavior - OK on Windows, not on Linux

  1. #1
    Senior Member
    Join Date
    May 2015
    Location
    USA
    Posts
    1,084

    Reset behavior - OK on Windows, not on Linux

    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 by jonr; 02-11-2016 at 09:43 PM.

  2. #2
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    25,206
    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.

  3. #3
    Senior Member
    Join Date
    May 2015
    Location
    USA
    Posts
    1,084
    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 by jonr; 02-11-2016 at 10:17 PM.

  4. #4
    Senior Member
    Join Date
    Dec 2014
    Posts
    311
    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.

  5. #5
    Senior Member
    Join Date
    May 2015
    Location
    USA
    Posts
    1,084
    Maybe Windows and Linux are using different USB speeds. Is there a way to force Linux to the slowest speed?

  6. #6
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    25,206
    Teensy always uses 12 Mbit/sec USB speed.

    1.5 Mbit/sec isn't supported at all.

  7. #7
    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-

  8. #8
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    25,206
    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.

  9. #9
    Senior Member
    Join Date
    Nov 2015
    Location
    Wales
    Posts
    579
    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

  10. #10
    Senior Member
    Join Date
    May 2015
    Location
    USA
    Posts
    1,084
    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 by jonr; 02-12-2016 at 12:47 PM.

  11. #11
    Senior Member
    Join Date
    Nov 2015
    Location
    Wales
    Posts
    579
    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?

  12. #12
    Senior Member
    Join Date
    May 2015
    Location
    USA
    Posts
    1,084
    Yes.

    Also, Linux may be using an older version of the Arduino software and Teensy loader - Greg?

  13. #13
    Senior Member
    Join Date
    Nov 2015
    Location
    Wales
    Posts
    579
    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

  14. #14
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    25,206
    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.

  15. #15
    Senior Member
    Join Date
    May 2015
    Location
    USA
    Posts
    1,084
    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 by jonr; 02-13-2016 at 01:25 PM.

  16. #16
    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.
    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.

    Attachment 6368

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

  17. #17
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    25,206
    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!

  18. #18
    Senior Member
    Join Date
    May 2015
    Location
    USA
    Posts
    1,084
    PJRC teensy works fine on Windows and Linux, custom teensy only programs on Windows.

  19. #19
    Senior Member
    Join Date
    May 2015
    Location
    USA
    Posts
    1,084
    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.

  20. #20
    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

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •