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

Thread: TeensyLoader CLI issues

  1. #1

    TeensyLoader CLI issues

    I compiled the CLI version of TeensyLoader v2.2 for linux (using Ubuntu 21.04). It compiled fine, it runs fine. But, it seems to have trouble actually flashing my board. I have a custom board with an M.2 socket for the Teensy MicroMod. I do have a button labeled "ERASE" that will trigger the proper functionality to boot into HalfKay.

    Here is what it looks like when I try to do a CLI firmware flash:

    collin@<mymachine>:$ ./teensy_loader_cli --mcu=TEENSY_MICROMOD -v -s -w GEVCU7.hex
    Teensy Loader, Command Line, Version 2.2
    Read "GEVCU7.hex": 272384 bytes, 1.6% usage
    Error opening USB device: No error
    Waiting for Teensy device...
    (hint: press the reset button) <I pushed the ERASE button at this point>
    Found HalfKay Bootloader
    Read "GEVCU7.hex": 272384 bytes, 1.6% usage
    Programming...error writing to Teensy

    collin@<mymachine>:$ ./teensy_loader_cli --mcu=TEENSY_MICROMOD -v -s -w GEVCU7.hex
    Teensy Loader, Command Line, Version 2.2
    Read "GEVCU7.hex": 272384 bytes, 1.6% usage
    Found HalfKay Bootloader
    Programming....................................... .................................................. .................................................. .................................................. .................................................. ........................
    Booting

    As you can see, first of all, it doesn't find the Teensy and wants me to push the button. I don't have to do this with the GUI TeensyLoader. It just plain works. Also, when I do push the button it fails immediately afterward. At that point a second run of the command will then flash the program and reboot.

    So, my questions are:
    1. Why does the GUI program automatically work but the CLI program needs help
    2. Why does the CLI program fail the first time I push the button but then a second run works perfectly?

    To answer the question of why I want this: I need to be able to have other people be able to easily flash these boards out in the field. The GUI program works but it requires that someone go find the HEX file, load it, and then be able to flash. The CLI should allow me to create a batch/script file and have people just click and go.

  2. #2
    Oh, an update that might point to the issue. In my case, the GEVCU7 program I am trying to flash uses the dual serial option as I have the second serial port for debugging output. One curious thing I've noticed is that the second port tends to be the one that the Arduino IDE lists as the Teensy port. It sees both serial ports but calls the second one the "official" one. I wonder if the CLI tool likewise sees both ports but wants to flash with the second one. This doesn't really seem to work. I always point the Arduino IDE to the first port and the GUI program works fine. So, could this be an issue with using dual serial ports in the compiled code?

  3. #3
    Well, due to lack of any suggestions I dug into this blindly myself and figured it out. As it turns out, there are two basic issues.

    1: A Teensy can take on multiple USB roles - keyboard, rawhid, serial, dual serial, etc. These have a range of product ID values but the CLI tool was hard coded to only attempt the "Serial" configuration. Several of the others will work too. It appears the only thing needed by the CLI tool to do a soft reset is that "Serial" exists in the USB profile. So, I've modified the linux code to attempt all the product IDs one after another until it runs out or finds a product ID that does match. This can take a little bit of time to complete. I probably should re-order the list out of numerical order and into "most likely first" order. But, it works. Now the code can do a soft reset even if you have dual serial, triple serial, or Serial + MIDI, etc.

    2. Once you do the soft reset it would then fail while trying to program (as seen above). This is because it times out. As it turns out, in teensy_write 0.5 is too short of a timeout and the code needs a little longer for some reason. I changed the timeouts to 7 seconds for the first block and 1.5 seconds for all subsequent blocks. This works fine even after the soft reset.

    With these two changes I can flash programs to a Teensy MicroMod 100% of the time with linux. Windows had the same issues (doesn't soft reset so you have to push the button then if you push the button it fails the first time anyway) but I will have to implement soft reset in the CLI tool for Windows first. Then the new timeout should work and life should be good in both Windows and LINUX. I couldn't care less about OSX or BSD so if someone wants soft reset in those they'll have to do it.

    But, I'll put together all these fixes and issue a pull request.

  4. #4
    Senior Member
    Join Date
    Jul 2014
    Posts
    3,373
    There are two modes Teensloader_CLI put teensy into programming mode (at least the version I have)
    - changing baudrate when (USB) Serial is used
    - send some bytes when HID is used.

  5. #5
    Thanks WMXZ. I found your existing pull request from 5+ years ago and applied it to the current source code of the V2.2 CLI code. I then added several new product IDs possible on the Teensy MicroMod / T4.0 / T4.1. It works fine and does do a soft reset for me on Windows. I now have fully automated flashing on both Windows and LINUX. Either way, you run the script file and it does its thing without further user interaction. This is quite nice for those of us trying to support remote users. I probably should care about OSX support at some point. Personally I hate everything Apple stands for and think OSX looks like garbage and the GUI is awful but not everyone agrees. So, I'll probably have to support it.

    I suppose it's a little frustrating that you created a pull request more than 5 years ago and it has gone nowhere. This is necessary functionality and it seems nobody ever got it merged into the mainline. It's just frustrating that I spent a lot of time trying to figure this out and it turns out you already ran into it 5 years ago. But, I'm very grateful that you did and that you submitted the necessary code to make it work on Windows.

Posting Permissions

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