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

Thread: Over the air updates

  1. #76
    Quote Originally Posted by wangnick View Post
    Congratulations! Sometimes it helps just to know that it is possible, no?
    Yes and thanks to you, jonr and all the other contributors! This would not be possible on my own!


    Quote Originally Posted by wangnick View Post
    I'm a bit confused what you mean with lower and upper. There is a nice Memory Layout picture in https://www.pjrc.com/store/teensy40.html; you'll see that all regular code is copied into RAM1 at startup, leaving only FLASHMEM code and PROGMEM variables in flash memory. Teensy 4.0 flash starts at 0x60000000 and is 0x200000 in size. So I store the new firmware as received into the region starting at 0x60100000 first ("upper"), then I check, then I move to 0x60000000 ("lower") first erasing pages as I go, then I reboot. I don't bother to erase the "upper" half after copying as I want to make the "copy to lower and reboot" as fast and robust as possible, because indeed if that goes wrong the mechanism could well get stuck and then what's left is to revert to USB programming.
    In my mind, the lower was the higher number but I see now that I was wrong. I took the available memory 0x200000 subtracted the 0x10000 area and divided it into 2 leaving 0xF8000 in each section.
    So I can load up to a 0xF8000 byte file. I start building the new file at 0x600F8000 and when done move it up to 0x60000000.
    The only reason I erase the upper section after is the thinking of protecting my code. Also once the Lower is erased and the file is moved to 0x60000000 then if power is lost it will still work even if it's interrupted while erasing the Upper. I see no negative about erasing the upper after moving it. Please correct me if I'm wrong.



    Quote Originally Posted by wangnick View Post
    As I'm forwarding the Intel Hex format data as I receive it streamed via MQTT my sender does not need to have the full file in memory.
    Interesting. I don't believe I'm talented enough to pull that off... yet.....



    Quote Originally Posted by wangnick View Post
    Yes, indeed, it's not bullet proof. More robust designs (companion uC talking CAN etc.) are surely possible, but also require a bit more effort.
    I started looking into making a very simple upload sketch to replace the 4K known good blink sketch that is located at the top of the memory. However, I found a comment by Paul that this area is irreversibly fused to read-only

    If there was a way to change this 4K area all I would have to expose is the button to make it so I never need the USB.


    I'm also thought about using an SD card or memory chip to hold the uploaded file then send to 0x60000000.
    But currently, my biggest file is only 10% of the 50% available to me with this type of upload.

  2. #77
    Senior Member
    Join Date
    Dec 2016
    Location
    Montreal, Canada
    Posts
    3,336
    I've written a CAN-CAN array sender with CRC verification, probably useful if you have the SD loaded or file in memory. It works on CAN2.0 and CANFD modes. But of course this is Teensy to Teensy specific. Payloads are dynamically adjusted with the transfers and capability (DLC) of the remote nodes (teensy)

  3. #78
    Junior Member
    Join Date
    Jan 2020
    Posts
    14
    Hello,

    Congratulations for the falsher 4 version !
    Works fine for me. I update via I2C from rapspberry.
    I have a question: is it possible to increased flashed code size ?
    #define MAX_FIRMWARE_SIZE (256 * 1024)
    to be replaced by
    #define MAX_FIRMWARE_SIZE (384 * 1024)

    I understand that is must be allocated in ram via malloc but why max is 256 Ko ?

    Regards

  4. #79
    Quote Originally Posted by PhilippeA View Post
    Hello,

    Congratulations for the falsher 4 version !
    Works fine for me. I update via I2C from rapspberry.
    I have a question: is it possible to increased flashed code size ?
    #define MAX_FIRMWARE_SIZE (256 * 1024)
    to be replaced by
    #define MAX_FIRMWARE_SIZE (384 * 1024)

    I understand that is must be allocated in ram via malloc but why max is 256 Ko ?

    Regards
    When I was playing with it I could increase the size to 0x50000 but I kept it at 0x40000 (256 * 1024) and just copied 0x40000 or less at a time until I filled half the available memory 0xF8000.

  5. #80
    Junior Member
    Join Date
    Jan 2020
    Posts
    14
    OK, I know I have some margin since I currently update by 140Kocts of program.
    For the moment it works very well.
    I free all the memory i can before to do the update.
    I am not very good at the memory usage, but I may understand that the malloc is on the second bank of 512k where as static and stack are on the first 512 Ko.
    Would be wonderfull if this is confirmed by someone

    Philippe

    Regards

  6. #81
    Senior Member+ MichaelMeissner's Avatar
    Join Date
    Nov 2012
    Location
    Ayer Massachussetts
    Posts
    3,680
    Quote Originally Posted by PhilippeA View Post
    OK, I know I have some margin since I currently update by 140Kocts of program.
    For the moment it works very well.
    I free all the memory i can before to do the update.
    I am not very good at the memory usage, but I may understand that the malloc is on the second bank of 512k where as static and stack are on the first 512 Ko.
    Would be wonderfull if this is confirmed by someone

    Philippe

    Regards
    If you go to the Teensy 4.0 product page (https://www.pjrc.com/store/teensy40.html), it has a graphic that shows the memory map.
    • Ram1 (512K) has the FASTRUN code; initialized static/global variables; uninitialized static/global variables; and the stack.
    • Ram2 (512K) has the DMAMEM variables, plus the space where malloc memory comes from.
    • Flash (2048K) has the FLASHMEM code, PROGMEM variables, the initial values that are copied into Ram1, EEPROM emulation, and the 4K restore program.

  7. #82
    Junior Member
    Join Date
    Mar 2020
    Posts
    3
    Hello All,

    I have been using the flasher code successfully with Teensy 3.2's but I am struggling 3.5's.

    Its not the code itself, but my HEX files. I am compiling using the Arduino IDE and Teensyduino, grabbing the HEX files from my temp folder:
    C:\Users\xx\AppData\Local\Temp

    This is fine for Teensy 3.2 where, it can write 4 byte words, but the 3.5 keeps throwing an error telling me the files arn't 64 bit. I have found an example of some pesky HEX:

    :04243C00F8B500BF30

    (Line 581)

    Is there anyway to force the compiler to create usable hex files?

    Cheers,
    Josh

  8. #83
    Quote Originally Posted by SI Josh View Post
    Hello All,

    I have been using the flasher code successfully with Teensy 3.2's but I am struggling 3.5's.

    Its not the code itself, but my HEX files. I am compiling using the Arduino IDE and Teensyduino, grabbing the HEX files from my temp folder:
    C:\Users\xx\AppData\Local\Temp

    This is fine for Teensy 3.2 where, it can write 4 byte words, but the 3.5 keeps throwing an error telling me the files arn't 64 bit. I have found an example of some pesky HEX:

    :04243C00F8B500BF30

    (Line 581)

    Is there anyway to force the compiler to create usable hex files?

    Cheers,
    Josh
    Not sure if this is helpful or not but when I am dealing with Hex files for 4.0 I used the Arduino ide under Sketch click Export compiled binary. This saves a file to the folder containing that sketch.
    Was faster and easier for me then finding it in the temp file location.

    I have never played with a 3.5 so I can't help with that.

  9. #84
    Junior Member
    Join Date
    Mar 2020
    Posts
    3
    Quote Originally Posted by bigboosted View Post
    Not sure if this is helpful or not but when I am dealing with Hex files for 4.0 I used the Arduino ide under Sketch click Export compiled binary. This saves a file to the folder containing that sketch.
    Was faster and easier for me then finding it in the temp file location.

    I have never played with a 3.5 so I can't help with that.
    Hi bigboosted,

    Thanks for the reply. This gives me a nice way of exported HEX files, cheers!

    Still no luck, I get these lines in my HEX files that means I can't flash them onto Teensy 3.5's:

    :08B79000016600003504000011
    :04B79800F8B500BF41
    :08B79C0068F3FF7F01000000CB

  10. #85
    Quote Originally Posted by SI Josh View Post
    Still no luck, I get these lines in my HEX files that means I can't flash them onto Teensy 3.5's:

    :08B79000016600003504000011
    :04B79800F8B500BF41
    :08B79C0068F3FF7F01000000CB
    If I'm not mistaken then this is an excerpt of a perfectly valid HEX file. So I guess you'd have to rewrite the flasher4 or whatever you use to buffer the binary stream as it is being decode, and to flush to flash only whenever you collected 8 bytes or the address changes, in the latter case padding the binary to complete 8 bytes.

    LG, Sebastian

  11. #86
    Junior Member
    Join Date
    Mar 2020
    Posts
    3
    Quote Originally Posted by wangnick View Post
    If I'm not mistaken then this is an excerpt of a perfectly valid HEX file. So I guess you'd have to rewrite the flasher4 or whatever you use to buffer the binary stream as it is being decode, and to flush to flash only whenever you collected 8 bytes or the address changes, in the latter case padding the binary to complete 8 bytes.

    LG, Sebastian
    Hi Wangnick,

    I got this working in the end.

    I read the whole HEX file in, picking out the data and ignoring the checksums etc. I then send this down to the controller in 16 byte chunks, in the same format as a HEX file, writing my own intel checksums at the end of each line. It was... intensive. Its the first time I have dealt with the HEX file format, but a nice little project.

    This works for both Teensy 3.5 and 3.2.

    Cheers,
    Josh

  12. #87
    Junior Member
    Join Date
    Dec 2018
    Posts
    16
    Quote Originally Posted by SI Josh View Post
    Hi Wangnick,

    I got this working in the end.

    I read the whole HEX file in, picking out the data and ignoring the checksums etc. I then send this down to the controller in 16 byte chunks, in the same format as a HEX file, writing my own intel checksums at the end of each line. It was... intensive. Its the first time I have dealt with the HEX file format, but a nice little project.

    This works for both Teensy 3.5 and 3.2.

    Cheers,
    Josh
    Hi Josh,

    Can you provide any example code with this working? I'm having the same issue on a T3.6 where my compiled hex also contains some 4 and 8 byte lines, meaning that when I try to flash I get a flash block align error.

    Cheers.

Posting Permissions

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