Uploading "Teensyduino" hex file to a raw Kinetis microcontroller

[stw]

I absolutely love Teensy. The easily-breadboarded development, the USB programming bootloader, and other features it has. The simplicity of Arduino, but the power of a modern ARM processor. What can't you love?

But the biggest thing I love is the fact that you can write high-level C using the Arduino IDE in order to program it. There's nothing more annoying than memorising propriety HAL architecture layers (STM has their own, Nordic has their own, Kinetis has their own, etc. etc.), and setting up an appropriate development environment when starting a project.

So I was wondering - if I were to place a lone Kinetis microcontroller rather than an entire Teensy module onto a custom PCB (MK66FX1M0VMD18 in-place of the Teensy 3.6, for example), would it be possible to still write this high-level C and program it to the board?

I know the USB programming is another whole story in itself - I'm saying here assuming I have a proper serial wire debug (SWDIO/SWCLK) programmer, using the appropriate pins on the Kinetis to program it. Is it possible to generate a single hex-file from the Arduino IDE (which would, for example, use the included libraries, examples, etc.), and then upload this to the Kinetis chip? Or is there some "meta" layer of firmware that only the Teensy modules have, which is required in order for things to work?

I'm not even sure if it's possible to generate a hex file from the Arduino IDE in the first place. But assuming it was...


Thanks

 

[defragster]

Arduino does create a HEX: Sketch / Export compiled Binary

The MCU and layout would have to match the Teensy to use Paul's work - like this :: https://www.oshpark.com/shared_projects/XbimUyLX

 

[stw]

Oh awesome. Thanks for the reply.

So yeah - assuming the hardware was fine (stable power supply, correct bypass caps, correct external oscillator, etc.) there's no tricks needed when uploading the firmware over SWD? All the stacked layers of architecture are already handled for and everything that's needed is in the 1 hex file?

Thanks again!

 

[defragster]

... the Teensy - like that reference board - uses the tricked out secondary bootloader MCU to do the programming over USB to give the PJRC experience

 

[rjp]

I absolutely love Teensy. The easily-breadboarded development, the USB programming bootloader, and other features it has. The simplicity of Arduino, but the power of a modern ARM processor. What can't you love?

But the biggest thing I love is the fact that you can write high-level C using the Arduino IDE in order to program it. There's nothing more annoying than memorising propriety HAL architecture layers (STM has their own, Nordic has their own, Kinetis has their own, etc. etc.), and setting up an appropriate development environment when starting a project.

So I was wondering - if I were to place a lone Kinetis microcontroller rather than an entire Teensy module onto a custom PCB (MK66FX1M0VMD18 in-place of the Teensy 3.6, for example), would it be possible to still write this high-level C and program it to the board?

I know the USB programming is another whole story in itself - I'm saying here assuming I have a proper serial wire debug (SWDIO/SWCLK) programmer, using the appropriate pins on the Kinetis to program it. Is it possible to generate a single hex-file from the Arduino IDE (which would, for example, use the included libraries, examples, etc.), and then upload this to the Kinetis chip? Or is there some "meta" layer of firmware that only the Teensy modules have, which is required in order for things to work?

I'm not even sure if it's possible to generate a hex file from the Arduino IDE in the first place. But assuming it was...


Thanks

you can steal the temporary hex file from the teensyuploader popup before it gets cleaned up.

when it has built and uploaded the popup is still around, goto the file menu and click open hex file.


then copy and paste the hex to somewhere safe.

 

[PaulStoffregen]

Or in Arduino, click File > Preferences and turn on verbose info while compiling. Then you can see the exact commands used, which will have all the filenames with full path info.

Yes, the HEX file should work when programmed into a bare chip. But if Arduino (actually, the teensy_reboot utility) sends the auto-reboot, the USB code will do a breakpoint instruction which is the signal to the bootloader chip to take over. If you don't have the bootloader chip present, your code will run the default exception handler which loops forever, effectively stopping your program. If you're going to make a HEX file for "production" use, you might wish to edit the USB code (usb_dev.c) and delete that support for requesting a reboot to the bootloader.

When you design your PCB, unless you're really cramped for space, it's a good idea to put the MKL02 bootloader chip into the design. Nearly all successful projects have a period where the firmware still changes. Having an easy way to update is probably worth the extra expense on the earliest boards. You can always decide later not to populate the part when you no longer need it. That's a lot less painful than a situation where you need to replace boards because you can't go a post-production or in-field update.