Forum Rule: Always post complete source code & details to reproduce any issue!
Page 8 of 9 FirstFirst ... 6 7 8 9 LastLast
Results 176 to 200 of 203

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

  1. #176
    Okay, that helps. First, as far as I know, you are the first to try to do this over I2C. If you look at the original FlasherX.ino sketch, you'll see that update_firmware gets called once and only once. If it returns to loop(), an error has occurred, and the Teensy will call REBOOT. Within update_firmware(), there is a loop that reads records from the specified serial stream, processing all records until an EOF is found. That loop calls read_ascii_line(), which reads from the specified stream until a newline is found. You need to replace read_ascii_line with a function that does the same thing, but reads from I2C rather than from the Serial stream. If you do that, you won't have to touch any of the other code. @jonr has suggested that the right way to do this is to implement a stream class for I2C, so the same code works for any stream, whether it be I2C, Serial, SPI, etc. For the time being, though, I suggest that you start with FlasherX.ino and try to modify read_ascii_line() to read records from I2C rather than a Serial stream.

  2. #177
    Thanks for the direction. Where I'm getting lost is that the i2c_t3 library calls a function on a packet received event, so I don't know how to implement this into a stream class. I'll give it a go and see where I get to with it.

  3. #178
    Looks like you are getting stuck inside that "while (!hex.eof)" loop which calls parse_hex_line multiple times on the same databuf before it get's updated. Need to exit out of there and more code to determine when you are done and it's time to flash.

  4. #179
    Quote Originally Posted by TomV View Post
    Thanks for the direction. Where I'm getting lost is that the i2c_t3 library calls a function on a packet received event, so I don't know how to implement this into a stream class. I'll give it a go and see where I get to with it.
    I spent some time today thinking about streams, and I looked at Stream.h in the Teensy cores and a few of the classes derived from Stream, such as HardwareSerial, Client, etc. As an example, I defined a Stream-based class to wrap the FIFO/LIFO defined in Arduino library CircularBuffer. I also looked at i2c_t3.h, and it already has available/read/peek/write functions, so I think you could do something like what I've shown below to create an I2C Stream. I'm pretty sure this is what @jonr had in mind with his suggestion regarding streams was to more directly implement a Stream on I2C/SPI/etc. You could use that stream on the "upper" (pass-through) T3.6 to connect your USB serial to I2C, and also on the "lower" T3.6 so read/write from I2C the same as if it was a serial port. There likely would be timing issues to consider.

    Code:
    #ifndef CBStream_h
    #define CBStream_h
    
    #include "Stream.h"
    #include "CircularBuffer.h"
    
    class CBStream : public Stream {
    
    public:
      virtual int    available(void)         { return CB.size(); }
      virtual int    peek(void)              { return CB.first(); }
      virtual int    read(void)              { return CB.shift(); }
      virtual void   flush(void)             { CB.clear(); }
      virtual void   clear(void)             { CB.clear(); }
      virtual int    availableForWrite(void) { return CB.available(); } 
      virtual size_t write(uint8_t value)    { return CB.push(value) ? 1 : 0; }
      
    //virtual size_t write(const uint8_t *buf, size_t size) =0;
    
    protected:
      CircularBuffer<uint8_t,100> CB;
    };
    
    #endif

  5. #180
    Thanks for this, I'll take a look into this approach. I have however got it working now by changing the read_ascii_line function to read from the i2c Bus. The function waits in the while loop until an i2c packet is received, the upper teensy is transmitting one line at a time, so each time the received function is called theres a full line of hex in the buffer to be parsed.

    I'm actually sending through 2 upper T3.6 now. USB Serial -> T3.6 -> UART -> MAX485 -> Max485 ->UART -> T3.6 -> I2C -> T3.6

    The upper teensy will become my 'flash tool' that connects to devices with an RS485 port. Inside these devices is sub pcbs on i2c. Next up is writing a protocol for the serial to direct files to the correct board, and a PC side piece of software to automate the entire update process. With no confirmations needed the software self updates if the Hex checks are passed, so multiple boards can be updated at once. Seems to be working reliably, even attempting to brick it by pulling power when copying to flash they've been able to be recovered by programming via USB using teensyloader

  6. #181
    Quote Originally Posted by TomV View Post
    The function waits in the while loop until an i2c packet is received, the upper teensy is transmitting one line at a time, so each time the received function is called there's a full line of hex in the buffer to be parsed. I'm actually sending through 2 upper T3.6 now.

    USB Serial -> T3.6 -> UART -> MAX485 -> Max485 ->UART -> T3.6 -> I2C -> T3.6

    The upper teensy will become my 'flash tool' that connects to devices with an RS485 port. Inside these devices is sub pcbs on i2c. Next up is writing a protocol for the serial to direct files to the correct board, and a PC side piece of software to automate the entire update process. With no confirmations needed the software self updates if the Hex checks are passed, so multiple boards can be updated at once. Seems to be working reliably, even attempting to brick it by pulling power when copying to flash they've been able to be recovered by programming via USB using teensyloader
    Wow, great work. We do something similar, but all UART-based, not I2C. We use a variation of the BISYNC protocol with 16-bit CRC and DLE-escaped byte stuffing. Device addresses and function codes are contained in the messages (inside the packets). Check out SerialTransfer for packetized communication. It's much more capable than EasyTransfer. The packets have a short header you could use for addresses. The payload is limited to 255 bytes, and it uses COBS, which I didn't know about until recently, so it's efficient in terms of byte stuffing.

    Be careful with those tests. I think that if you cut power in the short time between erase/write of the key sector, you could brick your T3.6.

  7. #182
    Name:  HexFiles.JPG
Views: 225
Size:  15.9 KB Click image for larger version. 

Name:	notepad.JPG 
Views:	6 
Size:	49.1 KB 
ID:	27318 Hello. First, million thanks for all your so needed inputs. I was able to download a blinking sketch from a server and upload it to my T3.6 without issues. All my tweaked blinking sketches are about 140K+. Eventually, I will be in need of uploading larger hex files than 140K. My hex file called StressTest.ino is about 510K. Since I don't know the limitations of my Flash memory, I don't want to upload this big file and brick my teensy trying to do he upload. I believe I read somewhere here that to see how much space is used I multiply total lines * 16. In my case, 11064 lines *16 bytes = 177024 bytes. Do I have enough flash space for a file this big on my T3.6? Do I need to extend the memory and the flash to this T3.6(Not sure if I have this option available with T3.6)? If is not possible to do this with a T3.6 is it possible to fit big files with 4.1. If if I need to add extra ram/flash to either card, the current FlashX sketch needs to be modified? Sorry about asking so many questions but I have no clue how to continue on. Thanks again.

  8. #183
    Quote Originally Posted by hbtousa View Post
    I believe I read somewhere here that to see how much space is used I multiply total lines * 16. In my case, 11064 lines *16 bytes = 177024 bytes. Do I have enough flash space for a file this big on my T3.6? Do I need to extend the memory and the flash to this T3.6(Not sure if I have this option available with T3.6)? If is not possible to do this with a T3.6 is it possible to fit big files with 4.1. If if I need to add extra ram/flash to either card, the current FlashX sketch needs to be modified? Sorry about asking so many questions but I have no clue how to continue on. Thanks again.
    The amount of flash for each Teensy is documented on the PJRC site (T3.6=1MB, T4.0=2MB, and T4.1= 8MB). For FlasherX, what matters is the CODE size, not the FILE size. FlasherX will use however much flash is available (empty) for the upload. During the download, FlasherX writes the new program to the empty flash, and when all of the new code has been transferred, it moves the new program to the "program" flash area. This is done one sector at a time. So, generally speaking, if your CODE requires less than HALF of the flash for your T3.6, you can use FlasherX. Also, if you try to load a larger file than will fit, FlasherX will detect that problem and abort, so it won't brick your board.

    Rebuild your StressTest program. At the end of the build process, the status window in the Arduino IDE will show the RAM and FLASH used/available. If it's well under 500K for a T3.6, you should be fine.

  9. #184
    Thank you very much. SIZE file is not issue, you were absolutely right. Everything worked perfect. Still more testing in progress. Posting pictures here to help to anyone somehow. Thanks again. Click image for larger version. 

Name:	UsedFlash.JPG 
Views:	9 
Size:	39.9 KB 
ID:	27339Click image for larger version. 

Name:	13759Lines.JPG 
Views:	8 
Size:	30.8 KB 
ID:	27340Click image for larger version. 

Name:	onserver605Kb.JPG 
Views:	9 
Size:	13.3 KB 
ID:	27341

  10. #185
    Hi Joe,

    To test FlasherX on a teensy 3.6, all I need to do is upload FlasherX.ino and after upload; open the Serial Terminal (i.e. Arduino) and load the .hex sketch includes contains #include "FlashTXX.h", println(FLASH_ID) in the sketch?

  11. #186
    Quote Originally Posted by mendez View Post
    Hi Joe, To test FlasherX on a teensy 3.6, all I need to do is upload FlasherX.ino and after upload; open the Serial Terminal (i.e. Arduino) and load the .hex sketch includes contains #include "FlashTXX.h", println(FLASH_ID) in the sketch?
    You need a serial terminal program with a file transfer capability. I use TeraTerm, and it works well. Here is an outline of how you can run/test FlasherX on T3.6

    1) Using Arduino IDE, build and run FlasherX on T3.6. If you open the Arduino serial monitor, you will see output from FlasherX.
    2) Close the Arduino serial monitor and open TeraTerm. Set up TeraTerm for the COM port assigned to your T3.6
    3) Press the button on the Teensy so it reboots and confirm that you see the Teensy output in TeraTerm.
    4) When you see the prompt to send a hex file to Teensy, go to the File menu for TeraTerm, and choose Send File
    5) Navigate to the folder that contains your FlasherX_ino.hex file and select the file
    6) You will see the file being sent. When it completes, FlasherX will tell you how many hex records it received.
    7) When you see the prompt, enter the number of hex records and hit Enter
    8) FlasherX will write the "new" firmware to flash and reboot

  12. #187
    Thanks. I loaded FlashedX and open the Arduino Serial Monitor and saw the output from FlasheX but immediatly the board got disconnected and now is not working. I might have damage the board and I understood the risk; I guess, how can I prevent this to happen again? I used 180Mhz and selected Teensy 3.6 for loading the FlasherX.ino. Thanks!


    Quote Originally Posted by joepasquariello View Post
    You need a serial terminal program with a file transfer capability. I use TeraTerm, and it works well. Here is an outline of how you can run/test FlasherX on T3.6

    1) Using Arduino IDE, build and run FlasherX on T3.6. If you open the Arduino serial monitor, you will see output from FlasherX.
    2) Close the Arduino serial monitor and open TeraTerm. Set up TeraTerm for the COM port assigned to your T3.6
    3) Press the button on the Teensy so it reboots and confirm that you see the Teensy output in TeraTerm.
    4) When you see the prompt to send a hex file to Teensy, go to the File menu for TeraTerm, and choose Send File
    5) Navigate to the folder that contains your FlasherX_ino.hex file and select the file
    6) You will see the file being sent. When it completes, FlasherX will tell you how many hex records it received.
    7) When you see the prompt, enter the number of hex records and hit Enter
    8) FlasherX will write the "new" firmware to flash and reboot

  13. #188
    Quote Originally Posted by mendez View Post
    Thanks. I loaded FlashedX and open the Arduino Serial Monitor and the output from FlasheX but immediatly the board got disconnected and now is not working. I might have damage the board and I understood the risk; I guess, how can I prevent this to happen again? I used 180Mhz and selected Teensy 3.6 for loading the FlasherX.ino. Thanks!
    Loading and running FlasherX on your board cannot damage it. The only risk is if you send a hex file and then tell FlasherX to write that program to flash. Try build/load a basic blink sketch. You might have to press the button on the Teensy to get it to load. Also, please tell us your dev platform (Windows? Linux? Mac?) and your version of Arduino and TeensyDuino. The latest versions are 1.8.16 and TeensyDuino 1.56.

  14. #189
    I was able to use it successfully; its great! Thanks for all your help. I was using a USB hub and it stopped working randomly. I'm using Arduino IDE v1.8.19 and TensyDuino 1.56.

    Question: I was able to upload the blink.hex file successfully using FlasherX; however, I tried to upload the file again (right after the first upload with FlasherX), and I noticed the uploading been very slow (see image) and it stopped at 49%. Any idea on why this my happened?

    My Blink.ino Code:

    Code:
    #include "FlashTXX.h"
    /* LED Blink, Teensyduino Tutorial #1
       http://www.pjrc.com/teensy/tutorial.html
     
       This example code is in the public domain.
    */
    
    // Teensy 2.0 has the LED on pin 11
    // Teensy++ 2.0 has the LED on pin 6
    // Teensy 3.x / Teensy LC have the LED on pin 13
    const int ledPin = 13;
    int i = 0;
    
    // the setup() method runs once, when the sketch starts
    
    void setup() {
      // initialize the digital pin as an output.
      pinMode(ledPin, OUTPUT);
      Serial.begin(115200);
      Serial.println(FLASH_ID);
    }
    
    // the loop() methor runs over and over again,
    // as long as the board has power
    
    void loop() {
      
      if (i >= 1000000) { digitalWrite(ledPin, HIGH); }  // set the LED on
      else if (i < 1000000) { digitalWrite(ledPin, LOW); }   // set the LED off
      if (i >= 2000000) { i = 0; }
      i++;
    }

    Click image for larger version. 

Name:	blink flasher.jpg 
Views:	20 
Size:	136.2 KB 
ID:	27576

    Quote Originally Posted by joepasquariello View Post
    Loading and running FlasherX on your board cannot damage it. The only risk is if you send a hex file and then tell FlasherX to write that program to flash. Try build/load a basic blink sketch. You might have to press the button on the Teensy to get it to load. Also, please tell us your dev platform (Windows? Linux? Mac?) and your version of Arduino and TeensyDuino. The latest versions are 1.8.16 and TeensyDuino 1.56.

  15. #190
    Quote Originally Posted by mendez View Post
    Question: I was able to upload the blink.hex file successfully using FlasherX; however, I tried to upload the file again (right after the first upload with FlasherX), and I noticed the uploading been very slow (see image) and it stopped at 49%. Any idea on why this my happened?
    Here is what you did:

    - build/load FlasherX.ino (Teensy is now running FlasherX.ino)
    - build Blink.ino
    - send Blink_ino.hex to Teensy (Teensy is now running Blink.ino)
    - send Blink_ino.hex to Teensy (fails because Blink.ino does not read hex records)

    Think of FlasherX.ino as a demo program that shows an example of how you can do firmware update within a Teensy sketch. Read this thread and you will find some guidance and examples of how to adapt FlasherX for your own purposes. What type of application are you trying to build, and how do you want to be able to install new firmware?

  16. #191
    Gotcha! I need to include FlasherX.ino in my code to allow future firmware updates. I'm trying to build an ESC and I will like to perform the firmware updates via SD. I noticed someone already shared an SD firmware update feature and that is my next step. I wanted to first understand how Flasherx works before starting to change codes.

    Question: Is there any limitation on the file size/lines that Flasher can perform updates? Example: my application uses 80% memory; thus, it has ~5500lines in the HEX file. Do I need to keep free space of at least 50% to perform updates?

    Thanks again for all your help and amazing work with FlasherX!


    Quote Originally Posted by joepasquariello View Post
    Here is what you did:

    - build/load FlasherX.ino (Teensy is now running FlasherX.ino)
    - build Blink.ino
    - send Blink_ino.hex to Teensy (Teensy is now running Blink.ino)
    - send Blink_ino.hex to Teensy (fails because Blink.ino does not read hex records)

    Think of FlasherX.ino as a demo program that shows an example of how you can do firmware update within a Teensy sketch. Read this thread and you will find some guidance and examples of how to adapt FlasherX for your own purposes. What type of application are you trying to build, and how do you want to be able to install new firmware?

  17. #192
    Junior Member
    Join Date
    Feb 2022
    Posts
    1
    Hey, everybody,
    I'm a new owner of a perfect Teensy 4.1 including Ethernet.

    The project I have implemented on arduino mega incl. perfectly working OTA update I have to abandon due to performance and memory constraints.

    Nowadays it is absolutely unavoidable to have OTA via ethernet ev. flash.

    I have an idea. After researching the HW wiring, I feel that there probably aren't many other options, so I'm not considering the bizarre idea of connecting another processor to the UART.

    Since I don't like the "undefined" buffer size and the move within flash.
    But what about this idea, behind the boot loader - use a small "loader" - this will start and read the value from the part of the emulated eeprom at address "0" and if it is zero, the process will continue normally. If it is other than zero, it should run update - it will jump to a specific function at a specific address (somewhere before the end of FLASH) - this will revive and mount the filesystem on the insert microSD card and try to replace the flash contents with the attached bin or hex file /update.bin. If successful, it will replace the value in "eerpom" at address 0 with 1 and reboot. The next time the reboot occurs, the process will be repeated, but it will go straight to running the executable code.

    The downside is that each project would have to include a piece of code to handle the update as well, at the "beginning" and then somewhere at the end of memory the actual function to perform the update.

    So nothing would be moved and the update could be done by inserting an SD card or embedded web server to transfer the update file.

    What is your opinion on this ?

    Thank you, M.

  18. #193
    Quote Originally Posted by mikr View Post
    Since I don't like the "undefined" buffer size and the move within flash.

    But what about this idea, behind the boot loader - use a small "loader" - this will start and read the value from the part of the emulated eeprom at address "0" and if it is zero, the process will continue normally. If it is other than zero, it should run update - it will jump to a specific function at a specific address (somewhere before the end of FLASH) - this will revive and mount the filesystem on the insert microSD card and try to replace the flash contents with the attached bin or hex file /update.bin. If successful, it will replace the value in "eerpom" at address 0 with 1 and reboot. The next time the reboot occurs, the process will be repeated, but it will go straight to running the executable code.

    The downside is that each project would have to include a piece of code to handle the update as well, at the "beginning" and then somewhere at the end of memory the actual function to perform the update.

    So nothing would be moved and the update could be done by inserting an SD card or embedded web server to transfer the update file.

    What is your opinion on this ?
    If you read this thread, you'll see there is at least one person loading new firmware from SD card. That should work fine. The way you propose to trigger the update sounds fine. I don't understand your loader concept, or what you mean by "behind the bootloader". If the file on SD is a hex file, you'll need the code to interpret hex records. You say you don't like the move within Flash, but at some point, you have to erase the existing firmware and write the new firmware. With T4.1, you have 8MB of flash, so unless your program is very large, buffering in flash is a good option. For my own purposes, there is no manual access, so the file must be sent via UART or I2C or SPI or Ethernet, and if it fits in flash, I wouldn't add an SD card to the process. If I was going to update from SD, I would want to implement some checksum method to be sure that the file was complete and that it had been read from SD correctly before erasing the existing firmware. If I had the space of a T4.1, I would read/buffer/erase/write, the same as FlasherX does now, though you could buffer elsewhere, such as additional flash or PSRAM. In any case, FlasherX is a good starting point for you to try this, and because the T4.1 has a recovery program built-in, you can experiment pretty safely.

  19. #194
    Senior Member Davidelvig's Avatar
    Join Date
    Aug 2015
    Location
    Wisconsin
    Posts
    334
    This is such great stuff! I'm going to see how it can apply in my case.

    I'm using Teensy 3.2 architecture on my board, and my toolchain is VSCode (Platformio) on Mac OS.
    The toolchain leverages the Teensy loader.
    The report at the end of the compile and link phase shows 56.9% Flash space used.

    Code:
    Building in release mode
    Linking .pio/build/teensy31/firmware.elf
    Checking size .pio/build/teensy31/firmware.elf
    Advanced Memory Usage is available via "PlatformIO Home > Project Inspect"
    RAM:   [====      ]  39.6% (used 25960 bytes from 65536 bytes)
    Flash: [======    ]  56.9% (used 149188 bytes from 262144 bytes)
    Building .pio/build/teensy31/firmware.hex
    1) I'm thinking my first goal (to keep things simple) is to trim the fat from my code... trying to get well under 50%. Is this 56.9% here the right metric?
    2) Any particular issues using the VS Code toolchain making the HEX file to implement this?

    Thanks!

  20. #195
    Quote Originally Posted by Davidelvig View Post
    Code:
    Building in release mode
    Linking .pio/build/teensy31/firmware.elf
    Checking size .pio/build/teensy31/firmware.elf
    Advanced Memory Usage is available via "PlatformIO Home > Project Inspect"
    RAM:   [====      ]  39.6% (used 25960 bytes from 65536 bytes)
    Flash: [======    ]  56.9% (used 149188 bytes from 262144 bytes)
    Building .pio/build/teensy31/firmware.hex
    1) I'm thinking my first goal (to keep things simple) is to trim the fat from my code... trying to get well under 50%. Is this 56.9% here the right metric?
    2) Any particular issues using the VS Code toolchain making the HEX file to implement this?
    Yes, you need to get below 50%, including the parts of FlasherX that will need to be included in your application. That's harder on the platforms with smaller flash, obviously. There are no issues that I know of with using PlatformIO. The HEX file should be the same or equivalent to the one generated via Arduino. The Arduino IDE provides a menu to choose different build options, such as minimize size, and I assume there is a way to access those options from PIO as well.

  21. #196
    Quote Originally Posted by ipaq3115 View Post
    I tried this on my T4.1 and it looks like FLASH_RESERVE is too small? I have data in my EEPROM section and the init stops at 0x607FC000 with a length of zero. From what I can see reading eeprom.c there are 63 sectors for EEPROM emulation, and the last sector is for the blink program.

    So something like this for the T4.1

    Code:
    #define FLASH_RESERVE		(64*FLASH_SECTOR_SIZE)	// reserve top of flash
    And 16 sectors for the T4.0

    Code:
    #define FLASH_RESERVE		(16*FLASH_SECTOR_SIZE)	// reserve top of flash
    Somebody should confirm that's right though, I only think I know how all that stuff is organized.

    P.S. - Looks like LittleFS_Program uses data below the EEPROM as well. That could create the same issue determining free space.
    Quote Originally Posted by joepasquariello View Post
    Okay, I found the info here (https://www.pjrc.com/teensy/td_code_security.html). For FlasherX, the user will have to configure the amount of upper flash they want to reserve. The default can be the space used for EEPROM, and they can increase if they use LittleFS or decrease if they do not use EEPROM. As before, after an update via FlasherX, all flash from the top of the new program to the bottom of the reserved space will be erased.
    I came across the same issue as @ipaq3115 when testing this, I also use the EEPROM in my program and when trying to flash I get "buffer = 0K FLASH (601FC000 - 601FC000)". I decided to use a ram buffer instead and modified flash_move to also erase the flash when using a ram buffer so that next time I could update using a flash buffer (I was assuming there was some left over data somewhere between the program and the EEPROM). When I tried using flash buffer again it still showed 0K Flash and my eeprom data was also messed up, which led me to believe that the buffer was cutting into the eeprom data. The product pages state that the top 64K (Teensy 4.0) and 256K (Teensy 4.1) are reserved for EEPROM and the restore program, This lines up with the flash reserve sizing that @ipaq3115 suggested (65536 bytes and 262144 bytes) and upon further testing, it seems to solve my issue on the Teensy 4.0 and 4.1. I believe these should be the new default values for the flash reserve on those two boards if the intention was to keep the EEPROM in tact. I am unsure about other boards, I only looked into and tested the 4.0 and 4.1 but I would guess the MicroMod has the same issue.

  22. #197
    Quote Originally Posted by Spencez View Post
    I came across the same issue as @ipaq3115 when testing this, I also use the EEPROM in my program and when trying to flash I get "buffer = 0K FLASH (601FC000 - 601FC000)". I decided to use a ram buffer instead and modified flash_move to also erase the flash when using a ram buffer so that next time I could update using a flash buffer (I was assuming there was some left over data somewhere between the program and the EEPROM). When I tried using flash buffer again it still showed 0K Flash and my eeprom data was also messed up, which led me to believe that the buffer was cutting into the eeprom data. The product pages state that the top 64K (Teensy 4.0) and 256K (Teensy 4.1) are reserved for EEPROM and the restore program, This lines up with the flash reserve sizing that @ipaq3115 suggested (65536 bytes and 262144 bytes) and upon further testing, it seems to solve my issue on the Teensy 4.0 and 4.1. I believe these should be the new default values for the flash reserve on those two boards if the intention was to keep the EEPROM in tact. I am unsure about other boards, I only looked into and tested the 4.0 and 4.1 but I would guess the MicroMod has the same issue.
    Okay, yes, I never updated FlasherX after Paul released Bootloader 1.07, and now that more folks are using LittleFS in program flash, I do need to do that. Could be a little while, but I'll get going on it.

    If your program is small enough to use a RAM buffer with FlasherX, that should always work and would avoid these issues entirely.

  23. #198
    Quote Originally Posted by joepasquariello View Post
    Okay, yes, I never updated FlasherX after Paul released Bootloader 1.07, and now that more folks are using LittleFS in program flash, I do need to do that. Could be a little while, but I'll get going on it.

    If your program is small enough to use a RAM buffer with FlasherX, that should always work and would avoid these issues entirely.
    No worries, in my case I am not using LittleFS, I just wanted to use the flash space between the program and EEPROM for buffering the new program. With the default offsets I was having the issues described above. Everything works great as long as the space is empty and I use the mentioned flash reserve offset. I was proposing updating the offset and letting people come up with their own offsets beyond that unless a better method is found.

    Did something change after the 1.07 Bootloader was released that changed the reserve offset? I'm confused at what changed that would affect this.
    Last edited by Spencez; 05-16-2022 at 05:29 AM.

  24. #199
    Quote Originally Posted by Spencez View Post
    No worries, in my case I am not using LittleFS, I just wanted to use the flash space between the program and EEPROM for buffering the new program. With the default offsets I was having the issues described above. Everything works great as long as the space is empty and I use the mentioned flash reserve offset. I was proposing updating the offset and letting people come up with their own offsets beyond that unless a better method is found.

    Did something change after the 1.07 Bootloader was released that changed the reserve offset? I'm confused at what changed that would affect this.
    What changed with Bootloader 1.07 is what is erased by the bootloader. See the section labeled Minimum Erase Size on this page (https://www.pjrc.com/teensy/td_code_security.html). If you are using EEPROM, you need to set FLASH_RESERVE to a larger value, and that would be the total space from top of flash to bottom of EEPROM space. Likewise, if you are using LittleFS, you must set FLASH_RESERVE to whatever value is required to incorporate everything you want to preserve. FlasherX will allocate the space from the bottom of your FLASH_RESERVE to the top of the existing firwmare as the buffer, so the max firmware size supported by FlasherX gets smaller as you reserve more flash for EEPROM and LittleFS.

    Perhaps I could make the FLASH_RESERVE space an argument to a FlasherX function, but for now you must edit the value of the macro in FlashTxx.h

  25. #200
    Quote Originally Posted by joepasquariello View Post
    What changed with Bootloader 1.07 is what is erased by the bootloader. See the section labeled Minimum Erase Size on this page (https://www.pjrc.com/teensy/td_code_security.html). If you are using EEPROM, you need to set FLASH_RESERVE to a larger value, and that would be the total space from top of flash to bottom of EEPROM space. Likewise, if you are using LittleFS, you must set FLASH_RESERVE to whatever value is required to incorporate everything you want to preserve. FlasherX will allocate the space from the bottom of your FLASH_RESERVE to the top of the existing firwmare as the buffer, so the max firmware size supported by FlasherX gets smaller as you reserve more flash for EEPROM and LittleFS.

    Perhaps I could make the FLASH_RESERVE space an argument to a FlasherX function, but for now you must edit the value of the macro in FlashTxx.h
    Thanks for the clarification and all your work on this, this should work perfectly for my needs I just need to send the file over ethernet. Assuming I verify the program with either a CRC or sending back each line, is this sufficient to ensure the program is correct? Is there a way to verify the program after it has been flashed?

Posting Permissions

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