Forum Rule: Always post complete source code & details to reproduce any issue!
Page 4 of 4 FirstFirst ... 2 3 4
Results 76 to 84 of 84

Thread: 'Over the Air' firmware updates, changes for flashing Teensy 3.5 & 3.6

  1. #76
    I've built a new version of Flasher to allow the largest possible upload by identifying empty sectors from the top of existing firmware to the bottom of flash reserve. This eliminates the need to explicitly specify the flash buffer location when building "small" or "large" programs, which gets very confusing. If an upload will not fit in the available space, you can use the two-step process of uploading a small program, and then uploading the larger one. The largest possible upload is FLASH_SIZE - smallest possible "flasher" program.

    There was one important change required to make this work. At the end of flash_move(), after the new firmware has overwritten the old, and before the reboot, flash is erased sector-by-sector from the top of the new firmware to the bottom of the flash reserve. This leaves the flash in the same condition as if the upload had been done with the Teensy loader, which seems like a good thing. Prior versions left the upper flash un-erased, so the first step for an upload was to call flash_erase_upper(), and that is no longer necessary. Other changes include adding a new argument uint32_t flash_buffer_addr to several functions.

    Let me know your thoughts, and I'll post the new version if you agree it sounds okay.

  2. #77
    Junior Member
    Join Date
    Dec 2020
    Quote Originally Posted by joepasquariello View Post
    @gonzales, yes, you're right. I simply replaced FLASH_SIZE/2 with FLASH_BUF_ADDR everywhere. In that case, the original code should have been (FLASH_SIZE - FLASH_SIZE/2 - RESERVE_FLASH) and the new code (FLASH_SIZE - FLASH_BUF_ADDR - RESERVE_FLASH).

    Let us know if it works correctly for you and I will upload another ZIP file with the correction.
    I tryed many times to flash my teensy 3.5. Work fine!!!

    joepasquariello - Thanks a lot!!!

    One more extension: for Teensy 3.5 you can use #define FLASH_BUFFER_ADDR (FLASH_SIZE/8) for small loader and #define FLASH_BUFFER_ADDR (7 * FLASH_SIZE/8) for large program, so you have 7/8 of flash size for you program/

  3. #78
    How can i use flasher over Ethernet?

    I have the Teensy Ethernet kit and want to try to update my firmware over ethernet.


  4. #79
    Over Ethernet is something I'm working on, have not been able to finish it yet. lots of other stuff todo.
    The path I'm on is sending the flash data in the body of a post request, then code the teensy side to strip the data out of the body.
    Sending the data is easy, Using curl to send the hex file in the body but I still need to write teensy code to handle the data.

  5. #80
    Junior Member
    Join Date
    Jan 2021
    Hi everyone

    I have one question, why are we using flasher4 or flasher3 is it because of that its not possible to write a new bootloader or modify the existing bootloader or is it because of its the only way for new methods for firmware updates

  6. #81
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Quote Originally Posted by the_boss View Post
    Hi everyone

    I have one question, why are we using flasher4 or flasher3 is it because of that its not possible to write a new bootloader or modify the existing bootloader or is it because of its the only way for new methods for firmware updates
    I answered your question about a month ago...
    No, it's not possible to write a new bootloader or to modify the existing one. It is protected.
    No you don't need flasher for firmware updates. Just use the bootloader
    Flasher is only needed if you don't want to use the default bootloader.

  7. #82
    What Frank said. If you need to do updates via Ethernet, work on getting Ethernet communication working, and you'll be able to combine with Flasher to do firmware updates that way.

  8. #83
    Senior Member Davidelvig's Avatar
    Join Date
    Aug 2015
    OK... trying to grok this...

    I'd like to Over-the-Air (OTA) update using BLE on a custom Teensy-3.2-designed board that has a Teensy Bootloader.
    The board also has an internal uSD card for temporary storage of a HEX if needed.

    My users will want the OTA nearly all of the time (from their phones) unless my OTA process "bricks" the Teensy while flashing...

    Than I'd love it if the user could connect the USB cable and use a TyCmd-wrapped PC/Mac app to initiate an "un-bricking".
    Most users would never need the PC/Mac app.

    Again, I have the Teensy bootloader chip on my board... I just want OTA as the routine solution.

    Is this a reasonable solution?
    Should I dig in to the Flasher option, knowing I can recover from a "Brick" with TyCmd, USB and a Teensy Bootloader?

  9. #84
    Yes, you can use the approach within Flasher3 for your OTA solution. Think of Flasher3 not as a production solution, but as an example of how to write new firmware to Flash once you have (somehow) transferred the new code to your board. Flasher3 does the transfer via USB serial and buffers the new code in unused (upper) program flash. If your application occupies less than 1/2 of the 256K T3.2 program flash, you can use this method, and I see no reason to use the SD card. If your program is larger than 128K (half of T3.2 program flash), you can still use Flasher3, but you have to do 2-step updates. Step 1 would be to write a small program to flash to make more flash available for buffering, and step 2 would be to send your new application using the now-larger available flash buffer. If you choose to buffer your code in the SD card rather than flash, you have some more development to do, but I think there are threads on the forum about other people doing that. Whichever way you buffer the new program, the code to erase the existing program and write the new program to Flash must be executed from RAM, with interrupts disabled. Flasher3 shows how to do that. Study it carefully before you try a new method, because there are ways that you can brick your board that are NOT recoverable via the Teensy bootloader. Specifically, when you write new code to T3.2 program flash, you MUST be certain to write the correct value to the FSEC and FOPT locations. If you fail to do that, you can brick your T3.2 in a way that is unrecoverable.

Posting Permissions

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