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

Thread: Teensy LC download problems.

  1. #1

    Teensy LC download problems.

    Hello,
    Ive got two Teensy LCs, one is fine but the other one will not re program.

    I can see it is running because the serial monitor shows output from the last program loaded, about 6 years ago.

    Here's the output:
    VMDPV_1|1_VMDPV
    Hello
    34567 |34567.00
    999 |999.00
    1000 |1000.00
    0.0 |0.00
    0.1 |0.10
    0.0 |0.01
    0.0 |0.00
    -0.1 |-0.10
    -0.0 |-0.01
    1013.3|1013.25
    1000.0|1000.00
    999.9 |999.90
    Pressure::begin
    setup done
    Pressing the boot button, following all the advice I've seen doesn't change anything. Windows 10 see the USB reset and reconnects but runs the original program.
    This is a verbose output from the loader:
    20:28:48.713 (serialmon 26): callback 0218
    20:32:23.389 (serialmon 26): callback 0218
    20:32:23.393 (serialmon 26): callback 0218
    20:52:02.947 (serialmon 26): teensy read ov error
    20:52:02.947 (serialmon 26): teensy read error
    20:52:02.951 (ports 2): WM_DEVICECHANGE DBT_DEVICEREMOVECOMPLETE
    20:52:02.951 (serialmon 26): WM_DEVICECHANGE DBT_DEVICEREMOVECOMPLETE
    20:52:02.952 (ports 2): remove: loc=usb:0/140000/0/2
    20:52:02.952 (serialmon 26): remove: loc=usb:0/140000/0/2
    20:52:02.952 (serialmon 26): usb_remove: usb:0/140000/0/2
    20:52:02.952 (ports 2): usb_remove: usb:0/140000/0/2
    20:52:02.952 (ports 2): nothing new, skipping HID & Ports enum
    20:52:02.952 (serialmon 26): Disconnect \\.\COM3
    20:52:02.952 (serialmon 26): nothing new, skipping HID & Ports enum
    20:52:02.972 (serialmon 26): WM_DEVICECHANGE DBT_DEVNODES_CHANGED
    20:52:02.972 (serialmon 26): WM_DEVICECHANGE DBT_DEVICEREMOVECOMPLETE
    20:52:02.973 (serialmon 26): nothing new, skipping HID & Ports enum
    20:52:02.979 (ports 2): WM_DEVICECHANGE DBT_DEVNODES_CHANGED
    20:52:02.980 (ports 2): WM_DEVICECHANGE DBT_DEVICEREMOVECOMPLETE
    20:52:02.980 (ports 2): nothing new, skipping HID & Ports enum
    20:52:03.706 (ports 2): WM_DEVICECHANGE DBT_DEVICEARRIVAL
    20:52:03.706 (serialmon 26): WM_DEVICECHANGE DBT_DEVICEARRIVAL
    20:52:03.706 (serialmon 26): found_usb_device, id=\\?\usb#vid_16c0&pid_0483#1553880#{a5dcbf10-6530-11d2-901f-00c04fb951ed}
    20:52:03.706 (serialmon 26): found_usb_device, loc=usb:0/140000/0/2 Port_#0002.Hub_#0001
    20:52:03.706 (serialmon 26): found_usb_device, hwid=USB\VID_16C0&PID_0483&REV_0100
    20:52:03.706 (serialmon 26): found_usb_device, devinst=00000004
    20:52:03.706 (serialmon 26): add: loc=usb:0/140000/0/2, class=Ports, vid=16C0, pid=0483, ver=0100, serial=1553880, dev=\\?\usb#vid_16c0&pid_0483#1553880#{a5dcbf10-6530-11d2-901f-00c04fb951ed}
    20:52:03.706 (serialmon 26): comport_from_devinst_list attempt
    20:52:03.706 (serialmon 26): found Ports in classguid_list at index=0
    20:52:03.706 (serialmon 26): port COM3 found from devnode
    20:52:03.706 (serialmon 26): found_usb_device complete
    20:52:03.707 (ports 2): found_usb_device, id=\\?\usb#vid_16c0&pid_0483#1553880#{a5dcbf10-6530-11d2-901f-00c04fb951ed}
    20:52:03.707 (ports 2): found_usb_device, loc=usb:0/140000/0/2 Port_#0002.Hub_#0001
    20:52:03.707 (ports 2): found_usb_device, hwid=USB\VID_16C0&PID_0483&REV_0100
    20:52:03.707 (ports 2): found_usb_device, devinst=00000004
    20:52:03.707 (ports 2): add: loc=usb:0/140000/0/2, class=Ports, vid=16C0, pid=0483, ver=0100, serial=1553880, dev=\\?\usb#vid_16c0&pid_0483#1553880#{a5dcbf10-6530-11d2-901f-00c04fb951ed}
    20:52:03.707 (ports 2): comport_from_devinst_list attempt
    20:52:03.707 (ports 2): found Ports in classguid_list at index=0
    20:52:03.707 (ports 2): port COM3 found from devnode
    20:52:03.707 (ports 2): found_usb_device complete
    20:52:03.708 (serialmon 26): usb_add: usb:0/140000/0/2
    20:52:03.708 (serialmon 26): translate "COM3" -> "\\.\COM3"
    20:52:03.708 (ports 2): usb_add: usb:0/140000/0/2 COM3 (Teensy) Serial
    20:52:03.737 (serialmon 26): GetDefaultCommConfig success
    20:52:03.761 (serialmon 26): SetDefaultCommConfig success
    20:52:03.761 (serialmon 26): Opened \\.\COM3 Serial
    20:52:03.764 (ports 2): callback 001A
    20:52:03.765 (serialmon 26): WM_DEVICECHANGE DBT_DEVICEARRIVAL
    20:52:03.765 (serialmon 26): WM_DEVICECHANGE DBT_DEVNODES_CHANGED
    20:52:03.766 (serialmon 26): callback 001A
    20:52:03.767 (serialmon 26): nothing new, skipping HID & Ports enum
    20:52:03.855 (ports 2): WM_DEVICECHANGE DBT_DEVNODES_CHANGED
    20:52:03.855 (ports 2): WM_DEVICECHANGE DBT_DEVICEARRIVAL
    20:52:03.856 (ports 2): nothing new, skipping HID & Ports enum
    20:52:03.907 (serialmon 26): WM_DEVICECHANGE DBT_DEVNODES_CHANGED
    20:52:03.907 (serialmon 26): nothing new, skipping HID & Ports enum
    20:52:03.936 (ports 2): WM_DEVICECHANGE DBT_DEVNODES_CHANGED
    20:52:03.936 (ports 2): nothing new, skipping HID & Ports enum
    The code that's running has quite a lot happening in an ISR, but that shouldn't matter, or should it?

    Chris.

  2. #2
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    16,364
    Does the computer have Teensy Loader open with a Teensy LC compatible program built and ready to upload?

    The Button on a Teensy is not Reset or 'boot' - but puts the Teensy into Program mode.

    If Teensy Loader is open and does not have a compatible program it cannot complete, the Teensy will just restart.

  3. #3
    Quote Originally Posted by defragster View Post
    Does the computer have Teensy Loader open with a Teensy LC compatible program built and ready to upload?

    The Button on a Teensy is not Reset or 'boot' - but puts the Teensy into Program mode.

    If Teensy Loader is open and does not have a compatible program it cannot complete, the Teensy will just restart.
    Of course I had a compatible program loaded in the loader. The blink program. And I had the loader running. Would not using the correct term for what the button does make a difference?

    The program that's running is doing a lot in a timer controlled interrupt service but with none of the hardware connected so it may be spending a lot of time in timeout loops. Could it be doing something that prevents the other processor running correctly in Program Mode?

    Chris

  4. #4
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    26,810
    I don't know what's causing the problem, but I can answer this:

    Quote Originally Posted by ChrisRowland View Post
    The code that's running has quite a lot happening in an ISR, but that shouldn't matter, or should it?
    .....
    The program that's running is doing a lot in a timer controlled interrupt service but with none of the hardware connected so it may be spending a lot of time in timeout loops. Could it be doing something that prevents the other processor running correctly in Program Mode?
    An ISR, or just ordinary code which calls noInterrupts() and never turns interrupts back on, can interfere with automatic programming by clicking the Upload button in Arduino. That process sends a special message over the USB port, so if the USB interrupt code isn't able to run, then Teensy can't hear the request from your PC.

    But an ISR should not be able to block entering programming mode by the pushbutton on Teensy.

  5. #5
    Thanks Paul,

    It looks as if the program mode processor is broken in some way, nothing to do but get another one.

    Chris

  6. #6
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    26,810
    Maybe look for signs of damage to the wires between the 2 chips. Since pressing the button is at least causing the bootloader chip to reboot the main processor, there's some chance the parts might still be good but just not able to communicate properly.

Posting Permissions

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