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

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,701
    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
    4,036
    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
    17
    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.

  13. #88
    Junior Member
    Join Date
    Apr 2020
    Posts
    4
    It seems the Teensy4 flash is sensitive to timing related issues. I was getting hangups during the flashing phase and stumbled across this thread - https://forum.pjrc.com/threads/57898...PROM-h-problem

    They mentioned that any other compilation setting other than O2 caused flash_wait to hang. I couldn't get O2 to work, but adding #pragma GCC optimize ("O1") to the front of code was the solution (or FASTRUN static void flash_wait() __attribute__((optimize("O1"))) ).
    Last edited by bleckers; 06-08-2020 at 05:51 AM.

  14. #89
    Senior Member
    Join Date
    May 2015
    Location
    USA
    Posts
    861
    I'll fix this if I can duplicate it. What arduino and teensyduino versions are you using?

  15. #90
    Junior Member
    Join Date
    Apr 2020
    Posts
    4
    Teensyduino version 1.52 and Arduino 1.8.12

  16. #91
    Senior Member
    Join Date
    May 2015
    Location
    USA
    Posts
    861
    Since flash_wait() is Paul's core code, I'll follow his lead and not change code to work around what appears to be a compiler issue. For now, note that you may need different optimization settings (fast, faster, fastest?) for any write to flash (eeprom or flasher4).

    Thanks for tracking down and reporting the issue.

  17. #92
    Hey guys, I've been trying to get T3.6 OTA working. It's almost there, but I'm crashing on the flash move. I can actually flash a super small hex file as long as it can flash completely before the address where the flash move crashes. Maybe somebody with more knowledge here would want to take a look? Or point me in a direction, I'd really like to make this work!

    I started with alex-arc's repo and fixed the part that accounted for and buffered the 4byte hex lines that the T3.6 hex files have. I can make it all the way through the SD card to flash process but the flash move crashes right at the erase for address 0x3000. (Note: I was running this lib in a different program and observed this same behavior, only crashing at a larger address, something like 0x13000 if I remember correctly)

    My best guess is that the flash_move function is being run from flash and not from ram even though it should be. Then the erase wipes out that function and causes a crash? Just a guess, I'm not very familiar with the inner workings of running flash/ram functions.

    My Fork: https://github.com/ipaq3115/Firmware...flash_from_udp
    Note that checking for compatible firmware is disabled so that I could compile a hex small enough to flash.

    I'm just flashing from the sdcard for now since that was easy.

    examples/sd_flasher_test/test/test.ino is the simple flasher program, reads test.hex from the root of the 3.6 sdcard and flashes it.
    examples/sd_flasher_test/test/test.hex is the flasher program compiled for the 3.6, flashing this from the sdcard will fail
    examples/sd_flasher_test/test2/test2.ino and the hex in that folder is just a tiny program that writes to Serial, this is the program that's small enough to actually flash and run

    Running Arduino 1.8.13 and teensyduino 1.53

  18. #93
    Senior Member
    Join Date
    May 2015
    Location
    USA
    Posts
    861
    Very minor change - leave interrupts off when done flashing.
    Attached Files Attached Files

  19. #94
    Senior Member
    Join Date
    May 2015
    Location
    USA
    Posts
    861
    See here for a newer, better teensy 3.x version:

    https://forum.pjrc.com/threads/43165...sy-3-5-amp-3-6

  20. #95
    Member
    Join Date
    Jul 2016
    Location
    Denmark
    Posts
    31
    Will your flasher4 program also work on T4.1 ?

  21. #96
    Senior Member
    Join Date
    May 2015
    Location
    USA
    Posts
    861
    Yes, it works on both 4.0 and 4.1.

  22. #97
    Does anyone have a working example of adapting flasher4 to load .hex firmware from an SD card? I've spent a fair number hours reading through this thread, the code, and the instructions, and can't quite figure out how to do it.
    I'd be eternally grateful if someone has already done this and was willing to share how they did it!

    Great work on this btw! Super excited to bring it to my projects!

    (Using a Teensy 4.1)

  23. #98
    Quote Originally Posted by isaacjacobson View Post
    Does anyone have a working example of adapting flasher4 to load .hex firmware from an SD card? I've spent a fair number hours reading through this thread, the code, and the instructions, and can't quite figure out how to do it.
    I'd be eternally grateful if someone has already done this and was willing to share how they did it!

    Great work on this btw! Super excited to bring it to my projects!

    (Using a Teensy 4.1)
    I have not. However it's pretty straight forward because the library is meant to be adapted for whatever you want. A hex file is just lines of text, you can read it in any text editor. You'll need to read each line of that file and pass it to the flash_hex_line(string) function in the flasher4 library. If you look at the upgrade_firmware() function in flasher4.ino you can see that it does pretty much this exact same thing with the serial port, you'll just replace the serial port read with a sdcard read from your hex file. There's lots of sdcard examples in the sdcard library that explain reading from a text file. After that, send a flash command string like this flash_hex_line(":flash 9999") once you are all done reading from the file. Replace 9999 with the number of lines that you read from the file.

Posting Permissions

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