Teensy 4.1 binary from alternate toolchain

sceaj

Member
Hi guys,

I am a long time lurker, but first time poster. I have been building projects with Teensies for several years using MCUXpresso. I have never had any trouble getting a hello world or blink app up and running on Teensy 3.2, 3.5, or 3.6. I have a 4.1 that am interested in experimenting with FreeRTOS on and it works great building/uploading binaries from Arduino. I seem to have hit a brickwall with the 4.1 building in MCUXpresso, however.

After studying the NXP docs and the Arduino produced hex file, it seems like I'm producing a proper hex, but I can't get it to run after a couple days of trying.

At this point here is what I have:

0x600000: FlexSPI Configuration Block - Basically just copied the Arduino generated block
0x601000: IVT - Similar, but not identical to Arduino generated (Differences are minor differences in the generated binary, e.g. entry is 0x602000)
0x601020: Boot Data Structure - Similar, but not identical, length is just set to 0x7C00 rather than the actual image size
0x602000: Start of vector table and code

From what I understand so far, this should be all that is needed. I'm assuming the HalfKay is setting the boot mode to b10 (Internal) either through the external pins or fuses.

As best I can tell, my image never makes it to the startup code. I have tried turning on the LED early in the startup but I have never been able to get it to turn on.

I would appreciate it if someone took pity on me and pointed out where I have gone astray. As an aside, I don't suppose there is any magic I could send to HalfKay that would boot the RT1062 in Serial Downloader mode??? Any and all suggestions welcome :confused:
 
I thought it might be helpful to include a disassembly so that those more knowledgeable than myself might see something that isn't correct.

I had to truncate the file to meet the upload size limits, but I believe all the startup relevant data is still available.
 

Attachments

  • MIMXRT1062xxxxA_Blink.txt
    194.1 KB · Views: 259
I too would like to use a standard tool, such as MCUxpresso (NXP's version of Eclipse). I have been successful using the Teensy loader to load some of the LPUART examples from NXP's SDK, as well as blinky and a couple others. Those work, but the USB "Hello World" does not, it is a bit tough to debug without JTAG/SWdebug. Still looking at possible differences that matter between Teensy and NXP RT1062 eval kit. Wonder if anyone else has been successful going down this path.
 
I too would like to use a standard tool, such as MCUxpresso (NXP's version of Eclipse). I have been successful using the Teensy loader to load some of the LPUART examples from NXP's SDK, as well as blinky and a couple others. Those work, but the USB "Hello World" does not, it is a bit tough to debug without JTAG/SWdebug. Still looking at possible differences that matter between Teensy and NXP RT1062 eval kit. Wonder if anyone else has been successful going down this path.

Hi Bruce, good to know you are interested too. May ask what you are changing in the project in order to have successful boot via Teensy Loader? For example, I tried the evkmimxrt1060_iled_blinky example and I wasn't successful. The only thing I changed was the pin assignment (no LED) and I also added a PRINTF (no debug console output). Did you change the FlexSPI config block? Thanks!
 
I started with evkmimxrt1060_iled_blinky from the NXP SDK. Then add .hex generation to the project properties -> C build -> settings -Build Steps -> post build

Code:
arm-none-eabi-size "${BuildArtifactFileName}"
arm-none-eabi-objcopy -v -O binary "${BuildArtifactFileName}" "${BuildArtifactFileBaseName}.bin"
arm-none-eabi-objcopy -v -O ihex "${BuildArtifactFileName}" "${BuildArtifactFileBaseName}.hex"
# checksum -p ${TargetChip} -d "${BuildArtifactFileBaseName}.bin"

Then just accessed the appropriate pins connected to Teensy LED

Code:
/*!
 * @brief Main function
 */
int main(void)
{
	volatile int i;
    /* Board pin init */
    BOARD_InitPins();
    BOARD_InitBootClocks();
    /* Update the core clock */
    SystemCoreClockUpdate();

     GPIO2->GDIR |= (1 << 3);

    while (1)
    {
        /* Delay 1000 ms */
        SysTick_DelayTicks(1000U);
        if (g_pinSet)
        {
            GPIO_PinWrite(GPIO2, 3, 0U);
            g_pinSet = false;
        }
        else
        {
            GPIO_PinWrite(GPIO2, 3, 1U);
            g_pinSet = true;
        }
    }

Built this code, and then used the Teensy Loader 1.53 to find the .hex file, load it, and run it

I did the same for a couple others including the LPUART1 example wires added to pins 24,25 and that worked

But so far the "hello world" examples do not, It would be nice to get the USB serial port working in this environment, but so far no
 
I'm assuming the HalfKay is setting the boot mode to b10 (Internal) either through the external pins or fuses.

Not sure if this really matters, but I can tell you boot mode 00 "Boot From Fuses" is used. We never use mode 10 "Internal Boot" on Teensy. The BOOT_MODE1 pin (AD_B0_05) is hard wired to GND, as you can see in the schematic.

If anyone's curious, this stuff is documented starting on page 202 of the IMXRT1060 reference manual (rev 2).
 
Thanks for your input bruceee and Paul. I've been working my way through the reference manual and the Teensyduino startup code.

bruceee: I wasn't so lucky with evkmimxrt1060_iled_blinky. For me, systicks are not generated. So the good news is that the Teensy boots and starts executing user code, but it was getting stuck in SysTick_DelayTicks so I had to modify it as:
Code:
void SysTick_DelayTicks(uint32_t n)
{
    g_systickCounter = n * 20000U;
    while (g_systickCounter != 0U)
    {
    	--g_systickCounter;
    }
}

My other project that I started from scratch, never seems to exit from the ROM? As best I can tell everything relevant to boot is pretty much the same between the KSDK sample and my project.

I'm developing on Windows and Teensy Loader 1.52 appears to be the latest version on that platform. I don't know why it would make a difference, but just out of curiosity, what platform are you developing on? Also, I'm using the latest KSDK, 2.8.2 - may I ask what version you're on?

I have been able to get the USB virtual device working on all the previous Teensys, but until I can reliably build the simple blink/uart debug console I can't move on to that :(
 
Hi, I realized that I am not alone in the universe. I am also looking for a way to program Teensy 4.1 without Arduino. I have seen that someone did project by using CircuitPython. However, I want to write a code by using MCUXpresso and load it to Teensy. If someone find a way to program Teensy 4.1 without Arduino, pls let me know. I will be happy. :)
 
I have a small debugger running on a Teensy 4.0 generated from MCUxpresso using pins 1,2 for serial (LPUART6 or RX1/TX1 according to PJRC)

Here is the.hex file, I'll post a zip of the project later today
https://eisenhard.net/eisenhard/files/evkmimxrt1060_lpuart_interrupt6.hex

The Teensy loader can load this (one way to get that loader is install the Arduino, then Teensy upgrade, then it is in Program Files (x86)/Arduino/hardware/tools directory.
 
Last edited:
Here is a zip of the MCUxpresso workspace -- still has a number of warnings, as I am still playing with merging my sources with the SDK sources.

https://eisenhard.net/eisenhard/files/Teensy_lpuart6_debug.zip

Back to what I see so far, blinky and these LPUART examples work, though I do not have either SDK hello_world examples working, which leads me to believe there is something before the printf keeping those from working.
 
can't seem to edit an earlier post, above my debugger talks to the serial lines on Teensy 4.0 pins 0,1

good to know there is an easier way to download the Teensy loader without needing to install Arduino, thanks WMXZ
 
bruceee - I was able to get the evkmimxrt1060_dev_cdc_vcom_bm bare metal USB virtual com sample running tonight. The zip was too large so a stuffed in a GitHub repo: https://github.com/sceaj/teensy41_vcom

I added some code that outputs a simple incrementing counter on the USB and a '.' on the debug console just so I could see something "happening". Some interesting points:

* The code seems to hang in APPInit() until I actually open the COM port with a terminal program.
* The code doesn't seem to be reading from the virtual COM port (it never echos what I type, but it writes fine).
* The debug console is opened on LPUART1 (Teensy pins 24/25)

BTW, that console monitor you had in your example is pretty neat. I'm still trying to understand what the difference between my from scratch project and these KSDK samples that run is :confused:
 
Sceaj- (finally back to Teensy4.0) I can compile and load the evkmimxrt1060_dev_cdc_vcom_bm MCUx example, and the VCOM port shows up, but I see no output (you seem to) and seems to accept no input.

I added a heartbeat from led_blinky so I can see the code is alive.

I tried Tera-Term and another Tcl based serial terminal. Neither see any output. So what are you using?
 
Not sure if this really matters, but I can tell you boot mode 00 "Boot From Fuses" is used. We never use mode 10 "Internal Boot" on Teensy. The BOOT_MODE1 pin (AD_B0_05) is hard wired to GND, as you can see in the schematic.

If anyone's curious, this stuff is documented starting on page 202 of the IMXRT1060 reference manual (rev 2).

hai i wanted to to a similar thing to this thread but took a different approach. i tried booting from serial and or SD card. my first attempt was to get it to boot from serial... i cut the trace AD_B0_04 going to the secondary mcu and soldered a jumper wire to the via on the bottom of the board to 3.3v, i got it to send a usb device descriptor(for the bare imxrt1060 mcu) but after that neither windows or linux would send data(checked on the scope) to the mcu after the USB device descriptor. thinking it was the secondary mcu messing with me i removed it(bad idea) i did some jenk soldering and go it to send the USB device descriptor again but same result... unfortunately after removing the secondary mcu i dropped it and couldn't find it to put it back on so that teensy is dead rip. i then thought that i was going to dump the boot fuses to see if i could find out why it was doing that or if i could get a way to boot from another source. the two questions i have are can u reprogram the fuses (it never explicitly says u cant except they are called OTP) and is there a way that u can think of that u could get it to boot from sd or other. i don't want to go down the wrong path of trying to get it to boot from another device if its not possible.
 
The OT in OTP is 'One Time' - AFAIK once they are set as done by PJRC to function as desired for Teensy.

based on Paul notes :: Indeed the bootloader MCU assists in timing and startup power distribution to the 1062 MCU so without it - it won't work.

Also - not on this thread - but when the code sent to Teensy doesn't start with a working USB descriptor the NXP descriptor appears - on that thread there was wonder if that would allow programming through that interface ... but not yet noted ...
 
Also - not on this thread - but when the code sent to Teensy doesn't start with a working USB descriptor the NXP descriptor appears - on that thread there was wonder if that would allow programming through that interface ... but not yet noted ...
intresting yeah i did get it to boot without the secondary mcu but with some jenk. i will look farther into this as it seems there is an easier way to get the npx usb descriptor to show. although
but when the code sent to Teensy doesn't start with a working USB descriptor the NXP descriptor appears
makes me think that that is just the default state the usb controller is set to. as for the OTP it states
Provides program-protect and read-protect eFuse
Provides override and read protection of shadow register
on page 1324 which makes me think that as long as there not locked u can reprogram them.

ill look more into it when i get the new teensy in the main as i lost the secondary mcu some where in my room after i took it off.. thx for the reply ill update u if any thing
 
if any one wants a memory dump of the boot fuses its
HTML:
0: 0x40528107 , ctrl: 0x00000000
1: 0x40528107 , ctrl: 0x00000001
2: 0x40528107 , ctrl: 0x00000002
3: 0x677f052f , ctrl: 0x00000003
4: 0x083a81d2 , ctrl: 0x00000004
5: 0x50000088 , ctrl: 0x00000005
6: 0x00420002 , ctrl: 0x00000006
7: 0x00000000 , ctrl: 0x00000007

u can also edit the fuses as they are not locked

the code i used is
 

Attachments

  • sketch_jan02a.ino
    66.3 KB · Views: 86
Last edited:
oops u cant write to it it just doesn't change when u write to it

and the reason booting from serial didn't work is because its disabled :(
 
HTML:
0: 0b11100000, 10000001, 01001010, 00000010 ctrl: 0x40528107
1: 0b11100000, 10000001, 01001010, 00000010 ctrl: 0x40528107
2: 0b11110100, 10100000, 11111110, 11100110 ctrl: 0x677f052f
3: 0b01001011, 10000001, 01011100, 00010000 ctrl: 0x083a81d2
4: 0b00010001, 00000000, 00000000, 00001010 ctrl: 0x50000088
5: 0b01000000, 00000000, 01000010, 00000000 ctrl: 0x00420002
6: 0b00000000, 00000000, 00000000, 00000000 ctrl: 0x00000000
7: 0b00011000, 00000000, 00010000, 00000000 ctrl: 0x00080018
 
Interesting to know the Serial is disabled - so even seeing the NXP bootloader appear won't allow access - that was a subject on another of these redundant threads.

The Fuses are dangerous - and indeed once set ( i.e. OTP - One Time Programmable ) they cannot be unset and some that can be can be locked to not be.

So there is some 'process' to enable and burn them as that can make the chip unusable as whatever they are set as on power up limits the ability of the chip to certain functions.
In order to avoid "rogue" code performing erroneous writes to OTP, a special unlocking
sequence is required for writes to the fuse banks.

That's part of the bootloader hold up making the right settings to enable desired functions and exclude others. The worst part is enabling the encryption and HAB is even less clearly documented and shown with general examples.

It is also why a 'virgin' new MCU won't work without having the fuses set as it boot 'wrong' from the factory to allow the bootloader to control the chip.
 
Back
Top