3.6 - Needing to press the program button to program the teensy :(

Status
Not open for further replies.

AndyCap

Well-known member
Hi Guys,

Depending on the USB type chosen the program button is needed every time to program the teensy. For example with USB_RAWHID the program button is not required and with USB_SERIAL the program button is required.

This is pretty annoying.

I thought this might be something to do with VENDOR_ID/PRODUCT_ID but it doesn't seem to be, what it seems to be is any USB type with a SEREMU_INTERFACE defined for serial emulation works without the program button, any without a SEREMU_INTERFACE need the program button to be pressed.

Is this normal?

Cheers

Andy
 
I decided to test it since I haven't used usb serial very much. It failed a couple times but seems to be working for serial, and serial+keyboard+mouse+joystick. (likely failed due to my slow computer, seems to be working as intended)

This is on teensy 3.6 and the latest arduino software plugin.
 
Last edited:
Andy - with a simple Blink programmed as USB_Serial it should work - with a single Teensy online connected should always work with a clean Arduino IDE and proper TeensyDuino install in place.

The sketch at this post should still work as a base blink showing some USB prints.

It should come up and work and allow IDE re-programming with subtle changes.

Unless the CORE PJRC build files were broken - or the running sketch FAULTS the USB - it should work.
 
Hi Guys,

Thanks very much for the replies.

I will do a clean install of the teensy software and arduino and have another test...

All the best

Andy
 
Hi Guys,

Thanks very much for your help, a re-install of arduino and the teensy software has fixed the issue :)

Also I see a fast flashing of the led when it is being programmed, I hadn't seen that before!

Once again thanks, pressing that button was driving me mad.

Andy
 
Hi Guys,

So I loaded up my project, programmed first time, super duper.

Second time programming problem is back, so know I know it is something to do with my code.

I found the problem, if you change the name of the USB Device it no longer works, this goes against what I have read about the reboot app which is meant to only use the IDs.

If I change the name back to default everything works fine.

So I'm guessing that there must be some duff info cached on this Mac that is confusing things maybe.

I will investigate further...

Cheers

Andy
 
Yeah, it looks like something to do with the Mac getting confused when I change the device name:

Code:
    | +-o Teensy MIDIx16/Audio@00110000  <class AppleUSBDevice, id 0x100006803, registered, matched, active, busy 0 (49 ms), retain 34>

Code:
    | +-o MIDI Processor@00110000  <class AppleUSBDevice, id 0x100006a41, registered, matched, active, busy 0 (50 ms), retain 34>

The IDs are different :(
 
Then, there is probably somewhere a little bug in your device renaming? I've done this several times using a custom xxxUSBconf.c and never ran into this issue on macOS High Sierra 10.13
 
Thanks for the info, are you changing both product and manufacturer name?

Here is the code I am using:

Code:
#include "usb_names.h"

#define MIDI_NAME   {'M','I','D','I', ' ', 'P', 'r', 'o', 'c', 'e', 's', 's', 'o', 'r'}
#define MIDI_NAME_LEN  14

#define MANU_NAME   {'C','t','r','l',' ','A','l','t',' ','D','e','l','e','t','e',' ','L','t','d','.'}
#define MANU_NAME_LEN  20


struct usb_string_descriptor_struct usb_string_product_name = {
        2 + MIDI_NAME_LEN * 2,
        3,
        MIDI_NAME
};

struct usb_string_descriptor_struct usb_string_manufacturer_name = {
        2 + MANU_NAME_LEN * 2,
        3,
        MANU_NAME
};

Thanks

Andy
 
Looks like we are doing similar things... :)

Code:
/*
 * dVoxUSBconf.c
 *
 *  Created on: 14 mai 2017
 *      Author: thierryfrenkel
 */


#include "usb_names.h"


#define PRODUCT_NAME			{'d','V','o','x',' ','C','o','r','e',' ','b','y',' ','T','h','F'}
#define PRODUCT_NAME_LEN		16
#define MANUFACTURER_NAME		{'d','V','o','x',' ','I','n','s','t','r','u','m','e','n','t','s'}
#define MANUFACTURER_NAME_LEN	16


struct usb_string_descriptor_struct usb_string_product_name = {
  2 + PRODUCT_NAME_LEN * 2,
  3,
  PRODUCT_NAME
};


struct usb_string_descriptor_struct usb_string_manufacturer_name = {
  2 + MANUFACTURER_NAME_LEN * 2,
  3,
  MANUFACTURER_NAME
};
 
Thanks for the info.

Same OS as well, High Sierra.

I have had a look for the reboot app code but it is not open source. I also looked at how to remove any USB Device cacheing in High Sierra but to no avail, you used to be able to do it in older versions by deleting the kernel caches but from what I can see using Google this seems to be a bit dangerous on HS so I am steering clear of that!

A simple solution for me at the moment is to stick with the default naming, for the future I am going to modify the teensy so I can connect a Segger Jlink to it for debugging so then I can program it via that rather than the teensy app.

Thanks for all your help on this, much appreciated.

Andy
 
If I read correctly, you didn't write which Teensyduino version you are currently using. V1.42beta3 introduced a reworked communication layer over USB to work around some buggy Arduino Java code. Did you give it a try?

As a notorious early adopter, I have that version running, together with Arduino 1.8.5, my High Sierra version is 10.13.5 beta, build 17F35e.
 
Nice, Thanks :)

I was just looking through the beta thread, a 64 bit version as well. Nice work.

Will give it a go a bit later, unfortunately I'm writing a user manual at the moment and I know if I stop I won't start again till tomorrow!
 
Hi Guys,

The beta cures the problem, all working without the button now :)

Thanks Theremingeniur for the pointer and Paul for the work.

Cheers

Andy
 
Hello,

So I solved my problem and wanted to share how here in case someone like me falls on this thread:

Step one

Setup teensy loader client in your environment: https://github.com/PaulStoffregen/teensy_loader_cli

Once that is setup you should execute the biranry first like so:

Code:
Code:
teensy_loader_cli.exe -w --mcu={version of teeny you are using} -v usb:{port} CompiledFirmwareUpdate.ino.hex

Step two

In your firmware add a functionality that will send a call to this function like this:
Code:

Code:
  delay(5000) ; //Need delay so other commands are not executed while reboot teensyduino is runnning
  _reboot_Teensyduino_();

to trigger it to restart it internaly

Once the device restarts, the first thing it will do is listen to see if there is something to be reprogram the microcontroller.

If you do this correctly you will not need to press the button to reprogram the teensy

Hope this helps !
 
Status
Not open for further replies.
Back
Top