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

Thread: teensy_loader_cli and Teensy 4.0?

  1. #1
    Senior Member
    Join Date
    Feb 2015
    Location
    Finland
    Posts
    123

    teensy_loader_cli and Teensy 4.0?

    Will teensy_loader_cli get support for Teensy 4.0?

  2. #2
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    20,576
    Yes, eventually.

    If you want to try now (editing the code yourself), the protocol is the same as Teensy 3.6. Block size is 1K. It has 1984 blocks instead of 1024.

    Might also need to allow longer delay on the 1st block, as erasing a previously fully written flash is slower than prior boards.

  3. #3
    Senior Member
    Join Date
    Feb 2015
    Location
    Finland
    Posts
    123
    Thanks. I don't have a 4.0 yet, but will do that when I get one.

  4. #4
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    5,422
    I think I have the changes in, which I still need to test, up at: https://github.com/KurtE/teensy_loader_cli/tree/T4

    I may next try plugging in RPI and see if I can program a new blink on a T4...

  5. #5
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    5,422
    Again I tried running this on RPI4...

    I was able to compile one of my programs for Teensy 3.2 on my Windows machine, winSCP over the hex file and use the built teensycli to program the T3.2

    Code:
    pi@RPI4B:~/teensy_loader_cli $ ./teensy_loader_cli --mcu=TEENSY31 -v -w Blink_any_pin.ino.TEENSY31.hex
    Teensy Loader, Command Line, Version 2.1
    Read "Blink_any_pin.ino.TEENSY31.hex": 32084 bytes, 12.2% usage
    Waiting for Teensy device...
     (hint: press the reset button)
    Found HalfKay Bootloader
    Read "Blink_any_pin.ino.TEENSY31.hex": 32084 bytes, 12.2% usage
    Programming................................
    Booting
    However if I then build the same program for Teensy40 and transfer and try to use the CLI, I see:
    Code:
    pi@RPI4B:~/teensy_loader_cli $ ./teensy_loader_cli --mcu=TEENSY40 -v -w Blink_any_pin.ino.TEENSY40.hex
    Teensy Loader, Command Line, Version 2.1
    Warning, HEX parse error line 2
    error reading intel hex file "Blink_any_pin.ino.TEENSY40.hex"
    pi@RPI4B:~/teensy_loader_cli $
    So there appears to be some differences that the CLI is not aware of...

    Here is the head of both generated files:
    Code:
    pi@RPI4B:~/teensy_loader_cli $ head Blink_any_pin.ino.TEENSY40.hex
    :0200000460009A
    :100000004643464200000156000000000101020084
    :1000100000000000000000000000000000000000E0
    :1000200000000000000000000000000000000000D0
    :1000300000000000000000000000000000000000C0
    :1000400000000000010403000000000000000000A8
    :100050000000200000000000000000000000000080
    :100060000000000000000000000000000000000090
    :100070000000000000000000000000000000000080
    :10008000EB04180A063204260000000000000000FD
    pi@RPI4B:~/teensy_loader_cli $ head Blink_any_pin.ino.TEENSY31.hex
    :1000000000800020BD010000850700003D070000C2
    :100010003D0700003D0700003D0700003D070000D0
    :100020003D0700003D0700003D0700008507000078
    :10003000850700003D070000051D0000091E0000A7
    :100040008507000085070000850700008507000080
    :100050008507000085070000850700008507000070
    :100060008507000085070000850700008507000060
    :100070008507000085070000850700008507000050
    :100080008507000085070000850700008507000040
    :100090008507000085070000850700008507000030
    pi@RPI4B:~/teensy_loader_cli $
    Edit: Might mention tail of each file shows differences in lines as well:
    (Obviously content would be different, but the 40 one is not filling full lines like the 31
    Code:
    pi@RPI4B:~/teensy_loader_cli $ tail Blink_any_pin.ino.TEENSY40.hex
    :107F2C00E80F0020E80F0020F00F0020F00F0020D9
    :107F3C00F80F0020F80F0020001000200010002087
    :107F4C000810002008100020101000201010002035
    :107F5C0018100020181000202010002020100020E5
    :107F6C002810002028100020301000203010002095
    :107F7C003810002038100020401000204010002045
    :107F8C0048100020481000205010002050100020F5
    :107F9C0000000200FFFFFFFF0000000000000000D7
    :040000056000100087
    :00000001FF
    pi@RPI4B:~/teensy_loader_cli $ tail Blink_any_pin.ino.TEENSY31.hex
    :107CC400F890FF1FF890FF1F0091FF1F0091FF1F06
    :107CD4000891FF1F0891FF1F1091FF1F1091FF1FB4
    :107CE4001891FF1F1891FF1F2091FF1F2091FF1F64
    :107CF4002891FF1F2891FF1F3091FF1F3091FF1F14
    :107D04003891FF1F3891FF1F4091FF1F4091FF1FC3
    :107D14004891FF1F4891FF1F5091FF1F5091FF1F73
    :107D24005891FF1F5891FF1F6091FF1F6091FF1F23
    :107D34006891FF1F6891FF1F7091FF1F7091FF1FD3
    :107D44007891FF1F7891FF1F00000200FFFFFFFFE3
    :00000001FF
    pi@RPI4B:~/teensy_loader_cli $

  6. #6
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    5,422
    Another quick update... I enabled some of the printf statements, and also a check to see if we were aborting due to size...
    Code:
    Line: length=2 Addr=0
    After addr... test: 2
    ext addr = 60000000
    Line: length=16 Addr=0
    Addr > Max: 1610612752 > 1048576
    Warning, HEX parse error line 2
    error reading intel hex file "Blink_any_pin.ino.TEENSY40.hex"
    So that first line is saying use an extended addr of 60000000 (hex) or 1610612736
    which exceeds what the program says it's max size is of: #define MAX_MEMORY_SIZE 0x100000
    Which our extended address blows that limit up!

  7. #7
    Junior Member
    Join Date
    Aug 2019
    Location
    world
    Posts
    4
    Thanks for taking the imitative KurtE!

    I am pretty new to using Teensy's, but started using the LC for a project which requires remote programming with a MIPS system. Now that the Teensy 4.0 is out, I have been wanting to replace my LC.

    I downloaded KurtE's teensy loader cli version and get the same results as KurtE. However if I remove the first line in the generated .hex file (the line that the teensy loader cli uses to generate the extremely large ext_addr), it loads onto the Teensy 4.0 just fine.

    What does this line do and is it important for loading a hex file?

    Here is the line of code I removed:
    Code:
    :0200000460009A

  8. #8
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    5,422
    @JtheBruce and @PaulStoffregen -

    The extended offset command in the first line: extended addr of 60000000 (hex) or 1610612736

    Is the address of the FlexSPI, which I am pretty sure is where the code gets downloaded to. It is also in this range that memory that is marked PROGMEM will be used from.

    I noted some of these regions in the thread, I recently started: https://forum.pjrc.com/threads/57326...ferent-regions

    What I am not sure of, is if it is safe to update the code to more or less ignore this offset. (Or more particularly on T4 reduce all memory addresses by 0x60000000

    This still does nothing about trying to properly initialize the RTC. Not sure how the Teensy loader does it.

    I don't imagine that it directly wacks the code in the reset vector:
    Code:
    	if (!(SNVS_LPCR & SNVS_LPCR_SRTC_ENV)) {
    		// if SRTC isn't running, start it with default Jan 1, 2019
    		SNVS_LPSRTCLR = 1546300800u << 15;
    		SNVS_LPSRTCMR = 1546300800u >> 17;
    		SNVS_LPCR |= SNVS_LPCR_SRTC_ENV;
    	}

  9. #9
    Junior Member
    Join Date
    Aug 2019
    Location
    world
    Posts
    4
    @KurtE

    Thanks for all the information and digging! I now have a much better grasp as to what is going on with the Teensy 4. Though I still am a bit confused as to where the Teensyduino compiler is putting the program.

    After looking at NXP's data sheets and reference manual as well as the Teeny 4 schematic, it seems that the Teensy 4 is setup with a "Serial NOR boot via FlexSPI" for its boot from fuses. I assume this is how the system reloads the blinking program after a ~15 second hold on the board's push button. Though this is a complete guess.

    For loading a main program, the information on Teensy 4's PJRC main page states that all of the Teensyduino code is loaded into the ITCM memory (which is located at memory map 0x0000_0000). I also assume this is why I was able to load a program onto the Teensy when I deleted the extended address line in the generated hex file.

    If we are suppose to write the code at the FlexSPI address, then the program will need to be rewritten to support storing the firmware as an array not directly referenced by the extended address and manipulate the address to match the extended address when we transfer this data through USB.

  10. #10
    Junior Member
    Join Date
    Aug 2019
    Location
    world
    Posts
    4
    @KurtE and @PaulStoffregen

    Kurt, I modified your T4 branch code to support loading a hex file to large extended addresses and created a pull request on your branch. I have verified this branch works for loading hex files onto my Teeny 4.0 and LC boards (using appropriately generated hex files for each). The main change is that the program stores the extended address as a global variable and adds it to the address counter when loading the data over USB in the main program. Internally, firmware is stored in the firmware array as if there was not extended address.

    I am unsure how extended addresses are handled on other boards, but the way I wrote the fix only supports extended addresses on boards that use block sizes of 512 or 1024. It should be easy enough to extend this to other block sizes. I just didn't know if it was necessary.

    You can fine my version of the T4 branch here.

  11. #11
    Junior Member
    Join Date
    Aug 2019
    Location
    world
    Posts
    4
    Just as a side note, I noticed the teensy loader cli doesn't soft reset the Teensy 4.0. When I try to use the -s option I get this error:

    Code:
    Unable to soft reboot with USB error: error sending control message: Broken pipe
    Any thoughts on why? It recognizes the board, but when trying to send the reset command it returns a less than zero.

  12. #12
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    5,422
    @JtheBruce,

    As I mentioned in the PR, I am no expert when it comes to these hex files.

    Your change is along the line, I thought about doing, where you ignore the extended address when you store the data into the array. My question to myself and others who know something about these files.

    Can these hex files have more than one offset record defined in them? If so, the data for each of these sections might collide with each other in the array. I thought about remembering the Min offset defined and store data relative to this and if a new offset that is lower than others, it might then need to move the data down in the array to make room... But again not sure if this is a real usage case or not?

    As for reboot stuff, again this is again a question for Paul.

  13. #13
    Teensy 4's flash seems to be mapped at 0x60000000, but the relevant sections of the binary are copied to RAM under lower addresses. As far as I understand https://github.com/PaulStoffregen/co...4/imxrt1062.ld and https://github.com/PaulStoffregen/co...rtup.c#L57-L59 just ignoring the 0x60000000 offset (or flashing to address 0x60000000 below) is the correct way.

    Shameless plug: I just published a reimplementation of teensy_loader_cli in Rust. It accepts ELF file as an input, so there's no `objdump` stage (but it doesn't handle ihex input, and it's libusb (Linux/FreeBSD only); patches for more platforms / input formats welcome, as long as they don't break ELF input on FreeBSD). It should handle Teensy 4, but I haven't tested that part yet. It flashes Teensy LC correctly and can reboot Teensy 3.6 and 4 from HalfKay to user code.

    If you feel like experimenting, take a look at https://crates.io/crates/teensy-loader (and there's also some Rust code for Teensy LC; Teensy 4 support in Rust is (hopefully) coming)

  14. #14
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    5,422
    In case anyone is needing a version of the command line Teensy loader. I merged in the earlier mentioned PR into my branch.

    I then added code to try to detect if we get multiple extended address records. In which case it remembers the smallest one, and if necessary move all previous data down by an offset for the newer lower range.

    Again this does nothing about whatever magic may happen in main Teensy app to set RTC or the like....

    I went ahead and issued a Pull Request: https://github.com/PaulStoffregen/te...er_cli/pull/48

    @PaulStoffregen - if you get a chance you might take a look at it, and see if it looks reasonable. I was able to build it on RPI3 and download a modified version of blink to a T4, as well as still update a T3.6.

Posting Permissions

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