Teensy LC download problems.

ChrisRowland

Active member
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.
 
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.
 
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
 
I don't know what's causing the problem, but I can answer this:

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.
 
Thanks Paul,

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

Chris
 
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.
 
Back
Top