teensy_loader_cli and Teensy 4.0?

Status
Not open for further replies.
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.
 
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 $
 
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!
 
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
 
@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-T4-0-Memory-trying-to-make-sense-of-the-different-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;
	}
 
@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.
 
@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.
 
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.
 
@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.
 
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/cores/blob/master/teensy4/imxrt1062.ld and https://github.com/PaulStoffregen/cores/blob/master/teensy4/startup.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)
 
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/teensy_loader_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.
 
Any updates/thoughts on getting the soft reboot to work for Teensy 4 in the teensy_loader_cli with the -s option?

I'm getting the same "Unable to soft reboot with USB error: error sending control message: Broken pipe" issue that @JtheBruce was having.

There are various discussions online that indicate the Broken Pipe error is often caused by the device stalling when a parameter is not correct in `usb_control_msg(...)` (like the request type or request value); I've monkeyed with various parameters in soft_reboot()'s usb_control_msg(...) line, but still no luck.
 
Ok, so I have a quick workaround for the Broken Pipe issue when trying to soft reboot a Teensy 4 (from a Raspberry Pi 4).

To request a soft reboot into the Halfkay Bootloader mode, usb_control_msg() was just setting the baud rate to 134. Since there are other ways to do that, we can just set the baud in a shell script before calling teensy_loader_cli and it work (most of the time).

For example, a shell script like this should do the trick.

---
SERIAL_TEENSY_DEVICE=`find /dev/serial/by-id/ -name "usb-Teensyduino*"`;
echo "-> Performing soft resset (baud = 134 hack). $SERIAL_TEENSY_DEVICE";
lsusb | grep Teensy;
stty -F $SERIAL_TEENSY_DEVICE 9600
sleep 1;
stty -F $SERIAL_TEENSY_DEVICE 134
sleep 1;
lsusb | grep Teensy;
echo "-> Should be ready to program...";
sudo ./teensy_loader_cli --mcu=imxrt1062 -v -w TEENSY4_CODE.hex
---
 
This of course only works if the Teensy has the serial interface activated. For the HID modes you need to send some magic bytes to the feature report of one of the interfaces. If you are interested here a c# snippet I used some time ago in a win application to start halfkay regardless of the USB mode. Don't know if it is possible to script it but a small application doing just that shouldn't be too difficult. If you are looking for c-code you can have a look at Koromix' tyTools GitHub repo. https://github.com/Koromix/tytools

Code:
bool doStartBootloader()
{
    if (isHalfKay) return true;
    else if (isSerial)
    {
       if (String.IsNullOrEmpty(ComPort)) return false;
       using (var port = new SerialPort(ComPort))
       {                  
           port.Open();
           port.BaudRate = 134; //This will switch the board to HalfKay. Don't try to access port after this...                                    
           return true;
        }
    }
    else
    {
        //Hack
        var device = HidDevices.Enumerate(pjrcVID)
           .Where(dev => parseHidSN(dev) == Serialnumber)                     // select all devices with correct serial number
           .FirstOrDefault(d => d.Capabilities.FeatureReportByteLength == 5); // looks like we need a device with exactly that length to issue a reset command                

        if (device != null)
        {
            device.WriteFeatureData(new byte[] { 0x00, 0xA9, 0x45, 0xC2, 0x6B });
            return true;
        }
   }
   return false;
 }
 
Just if anyone also try to bring teensy4 to work with platformIO's remote-feature:
You can paste the shell-code of 'Adam Kumpf' (https://forum.pjrc.com/threads/57176-teensy_loader_cli-and-Teensy-4-0?p=220204&viewfull=1#post220204) into the (right now empty) teensy_reboot script (located at the remote-end of the platformIO). Just search for 'teensy_remote' in the platformIO root-directory and paste the shell-code WITHOUT the last line into teensy_reboot.

And replace the internal platformIO version of teensy_loader_cli with a actual version (compiled from https://github.com/PaulStoffregen/teensy_loader_cli) if needed (see also https://community.platformio.org/t/how-to-remote-upload-to-teensy4).
 
Teensy 4.0 loader on Linux SBC

Hello All,
I'm trying to load a hex file for Teensy 4.0 on a ubuntu IoT SBC. This worked great on the 3.2, but I get an unknown MCU type "imxrt1062" when I modify the command for Teensy 4.0 like so: root@colibri-vf:~# teensy_loader_cli -mmcu=imxrt1062 -v -w -s U1-T40-2in2out_200311.ino.hex

Looks like it should work based on https://www.pjrc.com/teensy/loader_cli.html. I've tried -mmcu=imxrt1062, -mcu=imxrt1062, and --mcu=imxrt1062 (since the command that works on the T3.2 is teensy_loader_cli --mcu=mk20dx256 -v -w -s nameofhexfile.ino.hex). The problem seems to be the Unknown MCU type "imxrt1062".

So, I'm thinking the halfkay loader I'm using isn't current? Or the environment? Ideas? Thank You.
-J
 
Hello All,
I'm trying to load a hex file for Teensy 4.0 on a ubuntu IoT SBC. This worked great on the 3.2, but I get an unknown MCU type "imxrt1062" when I modify the command for Teensy 4.0 like so: root@colibri-vf:~# teensy_loader_cli -mmcu=imxrt1062 -v -w -s U1-T40-2in2out_200311.ino.hex

Looks like it should work based on https://www.pjrc.com/teensy/loader_cli.html. I've tried -mmcu=imxrt1062, -mcu=imxrt1062, and --mcu=imxrt1062 (since the command that works on the T3.2 is teensy_loader_cli --mcu=mk20dx256 -v -w -s nameofhexfile.ino.hex). The problem seems to be the Unknown MCU type "imxrt1062".

So, I'm thinking the halfkay loader I'm using isn't current? Or the environment? Ideas? Thank You.
-J

Platformio is working for me with these options on macOS:

teensy_loader_cli -mmcu=imxrt1062 -w -s -v .pio/build/teensy40/firmware.hex

You sure you have the latest teensy_loader_cli?
 
Thanks blackletter.....
I was wondering if that were the problem, because I think the version we have installed was last summer. Teensy 4.0 was fall 2019 I think. Will check that out,
Again, Thanks.
 
Status
Not open for further replies.
Back
Top