How to send a binary file for a customer to update a Teensy 3.2 system?

Status
Not open for further replies.

bboyes

Well-known member
I'm hoping there is a way that we can send a compiled Teensy 3.2 program to a customer and have them install it. They could install and use TeensyDuino, but not practical for them to have to use the Arduino IDE and recompile. We are working on a pretty complex commercial product and need to be able to send them prebuilt updates to load and test on their system. My guess is this must be a pretty common need.

I'm on Arduino 1.6.8 and TD 1.28 but plan to move to 1.6.9 and TD 1.29 later today.

I did google and search on the forums here but had no luck. I don't even know where the Arduino IDE (I only use it to compile, not to edit) puts its object and HEX files. I am on Windows 7 Pro 64 and also Windows 10 64 mainly (still working on the Linux thing).

I can see some Arduino files C:\Users\BAB\AppData\Local\Arduino15 updated today. preferences.txt is there and also a number of packages files (I don't know what those do) such as package_index.json also changed today.

From the compiler output window there should be files in a "buildxxx..." folder under Local\Temp but I don't see any such folder. But if I search the Temp folder for "build" I can see the folder name (build858bc...) - what is going on there? I can't see it in Windows Explorer but I can find it in a search? The path returned by search is really weird:
Code:
search-ms:displayname=Search%20Results%20in%20Temp&crumb=location:C%3A%5CUsers%5CBAB%5CAppData%5CLocal%5CTemp\build858bc23e5e69eeef06542b849ff25dff.tmp
- so where are these files, really? I do have Windows Control Panel Personalization set to show hidden files and folders and also to show operating system files.

There are files {sketchname}.eep, .elf, and .hex, so that is presumably what I need.

If I use the Teensy Loader app file menu, it is already aimed at the right file, in the folder I can't see in Windows Explorer: C:\Users\BAB\AppData\Local\Temp\build858bc23e5e69eeef06542b849ff25dff.tmp, and there is just the HEX file.

Trying to send it from Teensy Loader manually doesn't seem possible. The program and reboot buttons are grayed out, whether or not "Auto" mode is enabled. Pressing the program button on our board (the Teensy is harder to reach so we added PGM and RESET buttons on the edge of our PCB) works and loads the .hex file. Cool. That looks workable.

For now the customer will be able to reach the PGM button we've put there but it would easier for them to do it with a click on the screen. I read that the old loader CLI is not moving ahead and as long as TD can do the job that is actually preferable in this case.

At some point this may need to be done by a field service person, usually a contract electrician who has no familiarity with any of this hardware. If they could just plug in a USB stick or a uSD card and push a button that would be ideal. We will have Ethernet implemented so some way to push or pull an update from LAN or WAN might also be a future option. I'm guessing both of these are probably pipe dreams at this point.

Back to reality: remaining questions:
  1. Is there a way to make TeensyDuino send the HEX file from its on-screen load button?
  2. Where can I easily find and copy the .hex file from a compile?
  3. What's going on with the inability to see the "build858..." folder in Windows Explorer?
  4. Where does Arduino put object files, symbol tables, etc from a build?
  5. Would some or all of this be easier on Linux (on our developer end, not the field service end)?
 
If I use the TD file menu pulldown and back up a level I can see the mysterious "now you see it now you don't" build folder, copy and paste it's address into another Windows Explorer window and the files are there. If I back out a level in that Windows Explorer window, the folder is once again invisible, although the "forward" button will return me to the build folder. I'm in a very localized rupture in the space-time continuum.
 
Last edited:
Well things are not working quite as I had hoped. In the past I have always had the Arduino IDE open (just to compile). Today after a PC startup, I started just the TeensyDuino from arduino-1.6.9\hardware\tools, File->open to a saved copy of the .hex and .elf files (closing Arduino yesterday deleted the User\AppData...temporary folder). But I can't click to program and the program button doesn't seem to work either. Here's what I find is needed:
  1. Start TeensyDuino. All buttons except Auto are grayed out.
  2. Press the Teensy PGM button. All this does is ungray the TD load and reset buttons and the Teensy photo. It doesn't load a program.
  3. Click the load icon in TD, this actually sends the program to Teensy
  4. Clck the reset icon in TD, which actually resets Teensy
  5. Now all the TD buttons are grayed out again.
  6. If I want to load another program, use File->Open to start this process over.
  7. At this point I can "open" the same USB serial port used by TD in an app like RealTerm to get Serial output messages. Remember to "close" the port before trying to use TD to load again.

Is that how it is supposed to work? This is not a problem for me but might be confusing for a field service person. I was hoping they could open a HEX file and click load to send it. But then how does TD know which COM port to use, since Arduino is not open to tell TD such things.

In the tools folder I also see other tiny .exe files such as teensy_reboot.exe which doesn't seem to reset teensy if I run it. These are only useful to the TD application?

Also in my folder were the .eep and .elf and TD uses the .elf to compare file size (see it in verbose mode) but it also will just load with nothing but the .hex file so that is good.

Thanks...
 
I have not fully done this, but the steps I would probably try are:
1) Build the hex file into a known location: Try the Export Compiled Binary file command in the Sketch menu.

It should build the sketch and leave the hex file in your Sketch's directory.

2) Send the file

3) At other side: Run Teensyduino. In the File menu, click on Open Hex file and select your hex file.

4) Make sure your teensy you want is plugged in to USB to that computer and hit the program button on the Teensy. If it does not program the Teensy, try going into the Operation menu and make sure it is set for Automatic mode
 
Last edited:
@KurtE, yes, exactly what I did but (see my previous message from Jul 13) the Teensy load button is grayed out, auto is green. Requires the steps listed just above your post. I know that maybe seems weird but it's 100% repeatable. I didn't know about the Export Compiled Binary option, I was copying in File Explorer; I'll try that.
 
Yeah the export doesn't make sense until you need it.

TYQT might offer a better interface. The GUI is more complete and very functional, also a command line version. You'd have to read about licensing for your use case - but the tool is a great extension to Teensy.
 
I know that maybe seems weird but it's 100% repeatable.

Those steps should indeed be 100% repeatable.

Of course, step #1 is to click File > Open HEX File, and then use the standard file open dialog to locate the file on your computer. The sad reality is many PC users do not have the ability to know where locations are on their computer or use the open dialog to navigate to the place where they saved the file.

If the user is able to actually open the HEX file, then either turn on Auto mode and press the button on Teensy, or with Auto mode off, press the button on Teensy and then click the Program button.

Both of these paths require physically pressing the button on Teensy. Without Arduino, there isn't a way to cause Teensy to go into programming mode automatically from only your PC. The end user must press the physical button on Teensy to initiate programming mode.
 
Yeah the export doesn't make sense until you need it.

TYQT might offer a better interface. The GUI is more complete and very functional, also a command line version. You'd have to read about licensing for your use case - but the tool is a great extension to Teensy.

After using TyQt for a bit I agree: it's a wonderful tool. Am talking with @Koromix about some possible customization. It's a standalone solution too which is good in this case.
 
@PaulStoffregen one thing not planned for is that Teensyduino doesn't allow installation without Arduino being first installed; at least we could not get TD to do so. TyQT may be the best option
 
@PaulStoffregen one thing not planned for is that Teensyduino doesn't allow installation without Arduino being first installed; at least we could not get TD to do so. TyQT may be the best option


but once you as the developer installed TD, you can provide Teensy.exe with your .hex file to your customer.
Only you as the developer need TD installed to get access to Teensy.exe

all your customer has to do: go into folder with teensy.exe and .hex file, start teensy.exe, select hexfile, put teensy.exe into automatic mode, press prog button on T3.2 and off you go

TyQt, or the command-line teensy loader are more complicated alternatives than the plain Teensy.exe
 
I'm very interested in this post and will try the above. I'm considering making selling specialized data loggers for race cars and I wan't to be able to deliver updates to my customers but I don't want to give the source. I don't mind having the user press the program button, but is there a way to have Teensy simply read a file from an SD card (user would download an update, copy to SD card, press button done)? Id like to avoid plugging it to a PC and having the user run any software.
 
@KrisKasprzak Not that I am aware. Our system, which is starting to ship into the field now, loads a system configuration INI file from uSD, using an application we coded for that, uploaded over TyQt. Then we load the application HEX file from TyQt. Due to how the bootloader works, making Teensy load from uSD would be a major change. Our users don't need Arduino or any other tools, just TyQt and the files.

It would be better for our application to load over USB (the controller is in a box with no easy access) since we bring out the USB Micro B to a panel mount using these handy cables from DataPro; they are available in longer lengths than the usual 12". It would seem possible to have some USB stick computer (capable of USB Host mode) which could run something like TyQt and load a HEX file, but at the moment that's a pipe dream.

So current plans are for a service person to use a Windows PC with USB cable, TyQt, and they get the INI and HEX files from us.
 
Well, the teensy loader is so simple... just load the hexfile and press the button ?
There is a commandline-tool, too.
 
Right, but you need a Windows PC to do that. Also plugging in a Teensy of given USB VID is a painful three-step process before you can even load the code. It has to load three sets of "drivers" for every single Teensy you plug into every PC. We are in midst of doing 100 of them. It's a ridiculous process, takes a few minutes per Teensy and is really slow if you don't tell Windows to not search online for new drivers, but that means you are sitting there monitoring every one of the three steps and waiting for the chance to tell it not to. That's on Windows 7. Windows 10 is quite a bit faster, you don't have to tell it not to search online, but it still requires at least three attempts at loading the HEX file before it will finish the three USB setup sections and let you load the program. So the service people are going to have to put up with that.

I'm hoping Linux is quicker at this at least for our development and testing. I'm in midst of setting up a Linux desktop to have a go at this.
 
At my former company we were able to make the command line Teensy Loader work from within a Python application. We got it working on Mac OS and Linux, but didn't manage to make it work on Windows. We never entirely solved the problem of needing to press the button on the Teensy put it into programming mode. Sometimes the button press was needed. Sometimes not.
 
... It has to load three sets of "drivers" for every single Teensy you plug into every PC...

I had the same issue in a production environment a couple of years ago. Per default Windows "installs" the driver based on vid/pid and serial number of the device. However, you can force it to ignore the serial number which will speed up things significantly by changing a registry setting: https://msdn.microsoft.com/en-us/library/windows/hardware/jj649944(v=vs.85).aspx Look for IgnoreHWSerNum
 
.

I'm working with uTasker, its an open source and free encrypted bootloader that works perfectly with Kinetis MK64, MK66, so with Teensy 3.5 and 3.6, probably will works also with Teensy 3.2.

Just today I have send and update to a client, to load a new firmware version, and all is ok. I have configure my uTasker bootloader to load firmware by SD card.

If configure uTasker properly, user do not need push any button, simply insert SD card with new firmware, connect power supply, and uTasker bootloader load new firmware automatically.

https://github.com/uTasker/uTasker-Kinetis
http://www.utasker.com/
 
Status
Not open for further replies.
Back
Top