TEENSY 4.0 or 4.1 support

[ccrome]

I've attempted to bring up tinyuf2 on the TEENSY 4.1 but I'm not having any luck.

Here's what I've tried:

• Brought up tinyuf2 on the imxrt1060_evk and verified it works (mostly...).
• Created a new directory in ports/mimxrt10xx/boards/teensy41
• changed the config (as outlined below)
• tried to run

You can check out the mods here.

Just the diffs are:

diff -w -r imxrt1060_evk/board.h teensy41/board.h
32c32
< #define BOARD_FLASH_SIZE      (8*1024*1024)
---
> #define BOARD_FLASH_SIZE      (16*1024*1024)
38,40c38,40
< #define LED_PINMUX            IOMUXC_GPIO_AD_B0_09_GPIO1_IO09
< #define LED_PORT              GPIO1
< #define LED_PIN               9
---
> #define LED_PINMUX            IOMUXC_GPIO_B0_03_GPIO2_IO03
> #define LED_PORT              GPIO2
> #define LED_PIN               3
55,57c55,57
< #define BUTTON_PINMUX         IOMUXC_SNVS_WAKEUP_GPIO5_IO00
< #define BUTTON_PORT           GPIO5
< #define BUTTON_PIN            0
---
> #define BUTTON_PINMUX         IOMUXC_GPIO_B1_09_GPIO2_IO25
> #define BUTTON_PORT           GPIO2
> #define BUTTON_PIN            25
67c67
< #define USB_PRODUCT       "RT1060 EVK"
---
> #define USB_PRODUCT       "TEENSY"
70c70
< #define UF2_BOARD_ID      "MIMXRT1060-EVK-revA"
---
> #define UF2_BOARD_ID      "MIMXRT1060-TEENSY"

I built with

# make V=1 BOARD=teensy41 -j

And I load with:

teensy_loader_cli -w --mcu TEENSY41  _build/teensy41/tinyuf2-teensy41.hex

It appears that it attempts to run, because I get exactly one line in /var/log/syslog:

Feb 15 23:53:11 cc-i9 kernel: [ 3441.582567] usb 1-3.1.4: new high-speed USB device number 51 using xhci_hcd

followed by errors:

Feb 15 23:53:17 cc-i9 kernel: [ 3446.798540] usb 1-3.1.4: device descriptor read/64, error -110
Feb 15 23:53:32 cc-i9 kernel: [ 3462.410471] usb 1-3.1.4: device descriptor read/64, error -110
Feb 15 23:53:32 cc-i9 kernel: [ 3462.598474] usb 1-3.1.4: new high-speed USB device number 52 using xhci_hcd
Feb 15 23:53:38 cc-i9 kernel: [ 3467.786456] usb 1-3.1.4: device descriptor read/64, error -110

Any thoughts on how to make this work on teensy 4.1.

The real bear with the teensy is that there's no good way to connect jtag to it as far as I know.

[hathach]

uhh, isn't teensy 4.1 has its own bootloader already ? I haven't looked at this, but make sure you double check the flash layout of teensy bootloader vs tinyuf2. 2 bootloaders usually doesn't work together (it is either 1 or another most of the time).

[ccrome]

Okay, slightly more progress. If I program a bogus program into the flash (using tycmd), it then boots into the ROM loader by default. I was able to use the NXP-MCUFLASHLOADER to open up and read and write memory, once.

The initial key was to connect a serial port to TEENSY pins 24 and 25, which are the bootloader UART pins. Without that, it never enables the USB bootloader.

At this point, I can reliably get into the flashloader, but I somehow lost the magic to actually configure the flash. So the flashloader utility gets stuck with the message, "MCU has entered the Flashloader but failed to configure the external memory, Please reset the board and set proper boot device then try again".

I was able to access the flash once, but only once and I'm not sure what settings or process was different.

[ccrome]

sorry for live-blogging my debug session ;-)

But I was able to read the fuses:

[gsteiert]

Okay, slightly more progress. If I program a bogus program into the flash (using tycmd), it then boots into the ROM loader by default. I was able to use the NXP-MCUFLASHLOADER to open up and read and write memory, once.

The initial key was to connect a serial port to TEENSY pins 24 and 25, which are the bootloader UART pins. Without that, it never enables the USB bootloader.

At this point, I can reliably get into the flashloader, but I somehow lost the magic to actually configure the flash. So the flashloader utility gets stuck with the message, "MCU has entered the Flashloader but failed to configure the external memory, Please reset the board and set proper boot device then try again".

I was able to access the flash once, but only once and I'm not sure what settings or process was different.

If you can get into the ROM flashloader, then you can follow the instructions to load TinyUF2 with SPSDK sdphost.
I think this is what you need to do, because the .hex file will have RAM addresses not flash addresses, so the teensy loader would not load it correctly.

[gsteiert]

Get the board into the ROM bootloader mode and follow the Serial Download mode instructions in the mimxrt10xx directory.
https://github.com/adafruit/tinyuf2/tree/master/ports/mimxrt10xx
You can install SPSDK from PyPI. There are more docs on the tool here: https://spsdk.readthedocs.io/en/latest/apps/sdphost.html
You need to push the binary image into RAM and then it copies itself to the flash.

[ccrome]

Here are the commands from the NXP MCU Boot utility, and the final failure code (addresses translated to hex for sanity)

# 'Connect to xxx' button is clicked
sdphost -t 50000 -u 0x1FC9,0x0135 -j -- error-status
sdphost -t 50000 -u 0x1FC9,0x0135 -j -- read-register 1075790864 32 4 readReg.dat
sdphost -t 50000 -u 0x1FC9,0x0135 -j -- read-register 1075790880 32 4 readReg.dat
sdphost -t 50000 -u 0x1FC9,0x0135 -j -- read-register 1074757636 32 4 readReg.dat
sdphost -t 50000 -u 0x1FC9,0x0135 -j -- read-register 1074757660 32 4 readReg.dat
sdphost -t 50000 -u 0x1FC9,0x0135 -j -- read-register 1074757660 32 4 readReg.dat
sdphost -t 50000 -u 0x1FC9,0x0135 -j -- write-file 539001344 C:\Users\caleb\Downloads\NXP-MCUBootUtility-4.0.0\NXP-MCUBootUtility-4.0.0\src\targets\MIMXRT1062\ivt_flashloader.bin
sdphost -t 50000 -u 0x1FC9,0x0135 -j -- jump-address 539001344
#'Connect to xxx' button is clicked
blhost -t 50000 -u 0x15A2,0x0073 -j -- get-property 1 0
blhost -t 50000 -u 0x15A2,0x0073 -j -- get-property 1 0
blhost -t 50000 -u 0x15A2,0x0073 -j -- get-property 24 0
blhost -t 50000 -u 0x15A2,0x0073 -j -- efuse-read-once 5
blhost -t 50000 -u 0x15A2,0x0073 -j -- efuse-read-once 6
blhost -t 50000 -u 0x15A2,0x0073 -j -- efuse-read-once 7
blhost -t 50000 -u 0x15A2,0x0073 -j -- efuse-read-once 6
blhost -t 5242000 -u 0x15A2,0x0073 -j -- read-memory 0x400ac040 4 readReg.dat 0
blhost -t 5242000 -u 0x15A2,0x0073 -j -- read-memory 0x401f46d0 4 readReg.dat 0
#'Connect to xxx' button is clicked
blhost -t 5242000 -u 0x15A2,0x0073 -j -- fill-memory 0x20202000 4 0xc0000207 word
blhost -t 5242000 -u 0x15A2,0x0073 -j -- fill-memory 0x20202004 4 0 word
blhost -t 5242000 -u 0x15A2,0x0073 -j -- configure-memory 9 0x20202000  # This is where it fails

The last command fails with

{
   "command" : "configure-memory",
   "response" : [],
   "status" : {
      "description" : "20107 (0x4E8B) kStatus_FlexSPINOR_SFDP_NotFound",
      "value" : 20107
   }
}

I'm going on vacation for a week tomorrow, so might go dark. But I'm very interested in getting this working! Any hints would be great!

[gsteiert]

You actually do not need to load blhost, you load the TinyUF2 binary with sdphost and jump to it, then it copies itself to flash. This saves the step and eliminates blhost completely.

…

On Fri, Feb 17, 2023, 5:31 PM caleb crome ***@***.***> wrote: Here are the commands from the NXP MCU Boot utility, and the final failure code (addresses translated to hex for sanity) # 'Connect to xxx' button is clicked sdphost -t 50000 -u 0x1FC9,0x0135 -j -- error-status sdphost -t 50000 -u 0x1FC9,0x0135 -j -- read-register 1075790864 32 4 readReg.dat sdphost -t 50000 -u 0x1FC9,0x0135 -j -- read-register 1075790880 32 4 readReg.dat sdphost -t 50000 -u 0x1FC9,0x0135 -j -- read-register 1074757636 32 4 readReg.dat sdphost -t 50000 -u 0x1FC9,0x0135 -j -- read-register 1074757660 32 4 readReg.dat sdphost -t 50000 -u 0x1FC9,0x0135 -j -- read-register 1074757660 32 4 readReg.dat sdphost -t 50000 -u 0x1FC9,0x0135 -j -- write-file 539001344 C:\Users\caleb\Downloads\NXP-MCUBootUtility-4.0.0\NXP-MCUBootUtility-4.0.0\src\targets\MIMXRT1062\ivt_flashloader.bin sdphost -t 50000 -u 0x1FC9,0x0135 -j -- jump-address 539001344 #'Connect to xxx' button is clicked blhost -t 50000 -u 0x15A2,0x0073 -j -- get-property 1 0 blhost -t 50000 -u 0x15A2,0x0073 -j -- get-property 1 0 blhost -t 50000 -u 0x15A2,0x0073 -j -- get-property 24 0 blhost -t 50000 -u 0x15A2,0x0073 -j -- efuse-read-once 5 blhost -t 50000 -u 0x15A2,0x0073 -j -- efuse-read-once 6 blhost -t 50000 -u 0x15A2,0x0073 -j -- efuse-read-once 7 blhost -t 50000 -u 0x15A2,0x0073 -j -- efuse-read-once 6 blhost -t 5242000 -u 0x15A2,0x0073 -j -- read-memory 0x400ac040 4 readReg.dat 0 blhost -t 5242000 -u 0x15A2,0x0073 -j -- read-memory 0x401f46d0 4 readReg.dat 0 #'Connect to xxx' button is clicked blhost -t 5242000 -u 0x15A2,0x0073 -j -- fill-memory 0x20202000 4 0xc0000207 word blhost -t 5242000 -u 0x15A2,0x0073 -j -- fill-memory 0x20202004 4 0 word blhost -t 5242000 -u 0x15A2,0x0073 -j -- configure-memory 9 0x20202000 # This is where it fails The last command fails with { "command" : "configure-memory", "response" : [], "status" : { "description" : "20107 (0x4E8B) kStatus_FlexSPINOR_SFDP_NotFound", "value" : 20107 } } I'm going on vacation for a week tomorrow, so might go dark. But I'm very interested in getting this working! Any hints would be great! — Reply to this email directly, view it on GitHub <#285 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AJZ2HJQTZJEHI5HUBYZVUE3WYAQ7VANCNFSM6AAAAAAU5Z76JU> . You are receiving this because you commented.Message ID: ***@***.***>

[ccrome]

You actually do not need to load blhost, you load the TinyUF2 binary with sdphost and jump to it, then it copies itself to flash. This saves the step and eliminates blhost completely.

Oh! That explains why the hex file started at zero. I couldn't work out how it was supposed to work.

[gsteiert]

Good news! I was able to build your repository and load it into my Teensy 4.0 board
I loaded a bogus hex file with teensy loader to put it into serial download mode.
Then I installed spsdk and ran these commands from the build directory:
sdphost -u 0x1fc9,0x0135 write-file 0x1000 tinyuf2-teensy41.bin
sdphost -u 0x1fc9,0x0135 jump-address 0x2000

The magic numbers are:

• USB VID/PID for RT106x 0x1fc9,0x0135
• write address = _fcfb_origin from the linker script (0x1000)
• jump address = _ivt_origin from the linker script (0x2000)

The fcfb is the flash configuration block that needs to be loaded at 0x1000 on RT106x
The ivt is the vector table, this includes important addresses for the boot process
One of the addresses in the ivt is the boot data address. The boot data tells the boot ROM where the image should be located. This is how it knows the image is load to RAM, because the address is in RAM.

[gsteiert]

There are a couple ways to get around the ROM bootloader.
You can make a sketch that loads the code, like you suggest.
TinyUF2 includes flashloader update apps that do this, but they are linked to the application portion of memory. We could add the FCFB block to the app so it can be loaded directly into flash by teensy loader.
I think there should be a way to use arm-none-eabi-objcopy to convert the .bin file to a .hex file at the proper address, but I am not sure which argument sets the base address. Another way could be to simply read the image back out of flash after loading with sdphost.

[ccrome]

I think this might be roughly all we need: https://github.com/ccrome/tinyuf2/blob/teensy41/ports/mimxrt10xx/boards/teensy41/loader-loader/src/loader.ino. This just converts the .bin file to a .h file, and comples it into a sketch.

I didn't have all the docs available when writing this, so don't have all the right settings for the GPR registers, but does it look roughly right?

[gsteiert]

Using this objcopy command to convert the binary to hex, I was able to load TinyUF2 with Teensy Loader, then copy the CircuitPython .uf2 to the board succesfully:
arm-none-eabi-objcopy -I binary -O ihex --change-addresses 0x60000000 tinyuf2-teensy41.bin teensy-loader-UF2.hex

[hathach]

thank you @gsteiert for helping, I am glad you finally got it working.

[ccrome]

Using this objcopy command to convert the binary to hex, I was able to load TinyUF2 with Teensy Loader, then copy the CircuitPython .uf2 to the board succesfully:

arm-none-eabi-objcopy -I binary -O ihex --change-addresses 0x60000000 tinyuf2-teensy41.bin teensy-loader-UF2.hex

That's great! Looking forward to giving it a try.

Thanks!

[gsteiert]

First, you should check the Arduino linker files to make sure they do not use the RAM you are writing to. Second, TinyUF2 looks for fcfb to determine if it will copy itself to flash. You may need to clear this sector first, or add a way to force the load.

…

On Sun, Feb 19, 2023, 9:11 AM caleb crome ***@***.***> wrote: I think this might be roughly all we need: https://github.com/ccrome/tinyuf2/blob/teensy41/ports/mimxrt10xx/boards/teensy41/loader-loader/src/loader.ino. This just converts the .bin file to a .h file, and comples it into a sketch. I didn't have all the docs available when writing this, so don't have all the right settings for the GPR registers, but does it look roughly right? — Reply to this email directly, view it on GitHub <#285 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AJZ2HJSOLEHKA4WTBCE7EFTWYJH37ANCNFSM6AAAAAAU5Z76JU> . You are receiving this because you commented.Message ID: ***@***.***>

[gsteiert]

It should only take one objcopy command to generate the .hex that teensy loader can use. I'll try to figure it out later today.

…

On Sun, Feb 19, 2023, 9:11 AM caleb crome ***@***.***> wrote: I think this might be roughly all we need: https://github.com/ccrome/tinyuf2/blob/teensy41/ports/mimxrt10xx/boards/teensy41/loader-loader/src/loader.ino. This just converts the .bin file to a .h file, and comples it into a sketch. I didn't have all the docs available when writing this, so don't have all the right settings for the GPR registers, but does it look roughly right? — Reply to this email directly, view it on GitHub <#285 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AJZ2HJSOLEHKA4WTBCE7EFTWYJH37ANCNFSM6AAAAAAU5Z76JU> . You are receiving this because you commented.Message ID: ***@***.***>

[gsteiert]

Here is one way to generate a .hex file that Teensy Loader can load.
Build the project including the binary.
Run this command:
arm-none-eabi-objcopy -I binary -O ihex --change-addresses 0x60000000 tinyuf2-teensy41.bin teensy-loader-UF2.hex

This worked on my Teensy 4.0 board with the image I built from your repo.

The linker scripts should be able to take care of this and generate the correct load addresses automatically, but I did not implement the virtual and load addresses correctly.

[ccrome]

so awesome. It all works like a charm. I just created a PR for the Teensy 4.0 and 4.1 here . It's too easy :-)

[ccrome]

The linker scripts should be able to take care of this and generate the correct load addresses automatically, but I did not implement the virtual and load addresses correctly.

Doh! Just noticed this comment. It all actually works, so does anything need to change from what it is now?

[gsteiert]

The linker scripts should be able to take care of this and generate the correct load addresses automatically, but I did not implement the virtual and load addresses correctly.

Doh! Just noticed this comment. It all actually works, so does anything need to change from what it is now?

Converting the .bin is a simpler fix and should have the same effect. I'm not sure there is much value in modifying the linker script beyond hiding my ignorance on linker scripts. One thing I would consider doing a little differently. It would be nice to add the objcopy command to all RT10xx boards in case people want to load them with debuggers. You should still put a variable in board.mk to provide the FCFB/base address as this is varies between chips and which bus you are using, but the objcopy command could be in rules.mk, or port.mk

[ccrome]

I created PR #291. Let me know if you think anything else needs to be done. Right now, the objcopy only happens on the teensy boards. It would be easy to change to all boards.

[hathach]

I have reviewed the PR, don't worry about objcopy for now, I will update that on imxrt family later on when pulling out my board to test with.