How to upload to Teensy 3.2 with FTDI serial cable?

Status
Not open for further replies.

THX1138

Member
I have this FTDI serial cable and have installed the FTDI driver on my Win 7 machine. I have installed Teensyduino after Arduino 1.81. I have the red wire connected to VIN and black to GND. I have the white RXD and green TXD connected to pins 0 and 1 respectively. When I try to upload blink after pressing the bootloader button I get error

Teensy did not respond to a USB-based request to automatically reboot.
Please press the PROGRAM MODE BUTTON on your Teensy to upload your sketch.


I have left the RTS and CTS wires disconnected since they are not mentioned in this pinout image.

I'm using a Teensy 3.2. How do I connect with this cable? I need to do it this way because I want to underclock to 2 MHz and power from an old LiPo phone battery.
 
You can't upload to the Teensy using FTDI. You have to go through the USB cable and pressing the Program button to get the Teensy into program mode.
 
You can't upload to the Teensy using FTDI. You have to go through the USB cable and pressing the Program button to get the Teensy into program mode.

Are you sure about that? I have a Teensyduino screen that tells me to press the button to put the Teensy into Program mode. Furthermore it's not possible to use any of the underclocked modes below 24 MHz with USB.

hL3jx67.png
 
That's not how Teensy works. Uploading is only by the USB port.

You can use 2 MHz, but you will need to press the button on Teensy to upload, because the USB is not functional below 20 MHz.

When you press the button, Teensy will switch to bootloader mode. If powered from only a battery, your battery must be capable of running Teensy at the higher power level during the upload, which usually takes only a couple seconds.
 
Everything I try gives:

Teensy did not respond to a USB-based request to automatically reboot.
Please press the PROGRAM MODE BUTTON on your Teensy to upload your sketch.


Edit: I think there was something wrong with that USB port. It works in another one but sometimes the Teensy Loader thing gives an error message that the program is unreadable with this at the bottom of the Loader window: Blink.pde.hex (unreadable). If I click OK, it seems to load anyway.
 
Last edited:
Please understand how difficult it is to help. You're asking us to diagnose a problem which is happening on your computer, but you've typed only 14 words which tell us almost nothing. We can't even see if you use Mac, Windows or Linux. To answer "could you provide some help", I can try with this message, but given so little info, the odds are not good.

But I will try to give you some help about how *you* can try to find the problem... all blind without knowing anything about your computer.

Teensy Loader has a hidden window that gives more information. Click Help > Verbose info to access it.

After you click Verify in Arduino, it should show info like this:

01:38:03.146 (post_compile 17): Begin, version=1.46-beta7
01:38:03.146 (loader): remote connection 11 opened
01:38:03.147 (post_compile 17): Sending command: comment: Teensyduino 1.46-beta7 - LINUX64 (teensy_post_compile)
01:38:03.148 (loader): remote cmd from 11: "comment: Teensyduino 1.46-beta7 - LINUX64 (teensy_post_compile)"
01:38:03.149 (loader): remote cmd from 11: "status"
01:38:03.149 (loader): file changed
01:38:03.152 (loader): File "DS18x20_Temperature.pde.hex". 15044 bytes, 1% used
01:38:03.229 (post_compile 17): Status: 1, 1, 0, 2, 0, 0, /tmp/arduino_build_899657/, DS18x20_Temperature.pde.hex
01:38:03.229 (post_compile 17): Disconnect

On the 2nd to last line, you can see I've highlighted part of the line. This is the info about *where* on your computer Arduino created the HEX file. On Linux, it usually begins "/tmp". On Windows, it will usually be in an "AppData" or similar temporary folder. Macintosh uses a very complex randomly generated location, which is part of Apple's attempt to make Macs more secure (hackers can't easily guess where programs are creating temporary data). On both Windows and Mac, these locations may not be visible in the ordinary Finder or File Explorer, but you can use tools to access those locations. (can you understand how I'm having to write a longer message, because you didn't even tell us which type of computer you use?)

When Teensy Loader does the actual upload to your board, it will try to read the file from that folder. This error message means it could not read the file. Your job, once you know the full location and file name, is to try to figure out *why* the file is not accessible.

First, the obvious answer: if you quit Arduino, usually that temporary location will be deleted. It was created by Arduino, so it's considered to be no longer needed once Arduino is no longer running. Don't quit Arduino if you still want to access the file it created!

If Arduino is still running, the very first (and hopefully obvious) troubleshooting step is to inspect that location to see if the folder still exists and still contains the file. If the file is present, then the question becomes *why* can't Teensy Loader actually read it. But if the file has vanished, the question is what caused it to be deleted. Maybe some other software on your computer is overly aggressive about deleting temporary files which it believes are no longer needed? Or maybe something trying to improve security (like Apple's randomization of the folder names) has changed the name of the folder, but Teensy Loader is still trying to access the old location?

I don't know what's wrong. In fact, all I know is from those 14 words, which don't give much info. This explanation of how things work is meant to help *you* to solve the problem. Hopefully it helps? If you do discover what caused the problem, maybe you could take a moment to explain in a reply here, to help anyone else who has this issue in the future?
 
One more piece of advice.... if you find the HEX file and copy it (to a non-temporary location), also make a copy of the ELF file. Having the ELF file is optional, but it helps.

Without the ELF file, Teensy Loader can not check if you are programming the proper board. You don't strictly need the ELF file, but having it in the same folder as the HEX file can help avoid a confusing mistake where the code is made for the wrong board and doesn't work when run. With the ELF file present, Teensy Loader can detect this problem and give you a helpful message.
 
Just a quick followup here, regarding bugs that I recently discovered. These really should not apply to Teensy 3.x or Teensy 2.0 boards, which have correct linker scripts and where memory ranges are properly checked before the HEX file is created.

(msg #517 on this very long thread)
https://forum.pjrc.com/threads/54711-Teensy-4-0-First-Beta-Test?p=194724&viewfull=1#post194724

However, if a HEX file is created with corrupted data or with usage of memory outside the range your Teensy board supports, these invalid or corrupt files are mistakenly reported as "Teensy Loader is unable to read your compiled sketch (r)", when in fact Teensy Loader was able to read the file, but the data within the file was found to be corrupt or wrong.

So in addition to the file being missing, there's a real chance you could get this error is the file is corrupted somehow. Again, Arduino should never create a corrupted HEX file. Arduino does check the range of memory usage before making the HEX file, so you should never be able to get one like we had in the beta test (where the new beta software had a bug). If Arduino is creating wrong HEX files, that's something I'd very much like to investigate. I would need a copy of the HEX file and the exact steps used to make it. I can almost always get to the bottom of any such problem when I'm able to reproduce it here, but when I can't make it happen on any of my test machines, usually there's little I can do.

Corrupted files could also be caused by all sorts of other problems, like malware running on your computer.
 
Status
Not open for further replies.
Back
Top