Bootloader sequence

Status
Not open for further replies.

wwwoholic

Active member
Is there a detailed description of the bootloader functionality somewhere? I found bits and pieces in several threads but they provided more questions than answers. I am not asking for bootloader code, of course, just general information on how it all works together step by step.

Here is my understanding so far:
- Since MKL02 is not connected to USB data lines (only to sense pin) there is no way for it to communicate with loader software.
- MKL02 chip is connected to JTAG pins of MK20. This allows it to switch MCU into debug/programming mode and upload code into MCU flash.
- Conclusion: MKL02 is not a "bootloader". It is what is usually called "bootstrap", i.e. something that loads startup code into MCU.

If the above is correct then bootloader code gets loaded into MCU and executed. At this time it configures USB entry points, registers itself with USB host (using PJRC-owned device ID) and is available for programming. Here is inconsistency though - on several threads Paul mentioned that entire MCU flash is available for user code. I do not understand how this is possible, unless MKL02 is doing some crazy magic by supplying MCU one command at a time.

And final question - if there is an actual bootloader code that can be uploaded and run on MK20, can that code be loaded into MK20 permanently? With CRP or something to protect PJRC interests.

Now, for the real reason behind these questions. I have a project on backburner that is severely space-constrained. There is no way to fit loader chip on board. An option to buy MK20 pre-programmed with bootloader is very appealing to me.

To preempt suggestions like "write your own bootloader" I'd like to say - not everybody has time and/or (most important) skills for that. Or money to pay USB-IF for vendor ID. No matter how it sounds but people do prefer buying "solutions". In this case the solution is a combination of convenient hardware, reliable bootloader, USB programming + IDs, compatibility with huge volume of existing libraries and (from what I can see so far) great customer relationship and support. I certainly would like to keep all that, except after all testing and debugging is done I have to use different hardware in the final product.
 
There are some posts on here where folks talk about putting the MKL02 (well, actually the mini54 which was the Teensy 3.0/3.1 bootloader chip, but the same idea should be valid) onto a separate "programmer" board to use only for loading code onto the MK20, and thus saving the board space you mention.
 
There are some posts on here where folks talk about putting the MKL02 (well, actually the mini54 which was the Teensy 3.0/3.1 bootloader chip, but the same idea should be valid) onto a separate "programmer" board to use only for loading code onto the MK20, and thus saving the board space you mention.

This idea came to my mind right after I made a post. It is my understanding that MKL02 checks MK20 upon power up and uploads bootloader code if it is missing. Therefore it should be possible to separate the two and use this add-on to program MK20. What I do not know is if the code loaded into MK20 is capable of running alone. And when I say "running" I mean loading new user code from USB, not just starting the code previously loaded using MKL02. Having detailed boot sequence might help answering this question.

Having said that, the ability to program as many blank MK20 as necessary by buying single MKL02 chip seems unfair to PJRC. That is why I asked for pre-programmed MK20. This way I'll be getting fully functional Teensy and PJRC will get their royalties for bootloader. There are several board makers who use this marketing model. Although, there are also some that simply sell the right to use their bootloader for some reasonable one-time fee.
 
Last edited:
I do not understand how this is possible, unless MKL02 is doing some crazy magic by supplying MCU one command at a time.

And final question - if there is an actual bootloader code that can be uploaded and run on MK20, can that code be loaded into MK20 permanently? With CRP or something to protect PJRC interests.

AFAIK, Paul never described the process in detail, except that the MK02 is used to load the program to the MK20. Consider the following simplified approach, which may or may not be correct, but should work:
As soon the as the MK02 is put into program mode (program line pulled down), the MK02 puts the MK20 into "halt", copies a bootloader program into RAM, which itself talks to the host and receives the application program to be stored in flash. This way, you have all flash free for application program. Interesting enough, the MK20 can put the MK02 also in program mode.
You can therefore consider the MK02 as the bootloader- extension of the MK20. IMO, the best idea I have seen in years, so why change it? OK you need a separate chip on the board, but as madmattd said you could put the mk02 on a separate board if you need the space.
 
That is why I asked for pre-programmed MK20.
It seems that a MK20 with a PJRC bootloader code in FLASH will not be able to copy itself to RAM and to download application program, as it would overwite itself.

You will need a completely different concept, i.e. a NON-Teensy approach, which of course can be done.
 
Wow, I am obviously out of my comfort zone here. I did not know that you can run code from RAM, for example. That of course would allow user code to occupy entire flash.

But is "NON-Teensy" approach really that different, code-wise? I would say it is only a matter of accessible address range - bootloader either uses entire flash or protects it's own code page. Could be as simple as couple constants somewhere. The most important and complex parts of bootloader (namely - USB communication and Vendor ID) should be exactly the same, regardless where it is located.
 
But is "NON-Teensy" approach really that different, code-wise?
Well, you need to have code that is started from flash address zero (in case of Teensy SW there is the ResetHandler) of the application program. If this is your new bootloader, you can do what you want, e.g. call a main program that is stored at higher addresses, or interact with a host program to download now code that obviously must be stored at higher addresses. It is then your responsibility that the bootloader is not overwritten. Also, standard teensy programs may not run as the linker file puts an own interrupt vector table at zero address. So you need a separation of interrupt vector table from rest of the program, different loader files, etc. etc.
ALSO, you need in the beginning a possibility to load your bootloader program to the MK20, i.e. you use either PJRC's MK02 or any other programmer.
Again, the MK02 IS what other CPU's have in their BOOT-ROM.
 
I oversimplified a little, of course. Yes, some code to initiate programming condition either on reset or, for example, on interrupt from one of no longer used jtag pins. So, you are right, it is not THAT simple.
But I am not talking about writing my own bootloader, I do not have required skills yet. And even if I did I'd rather have MCU pre-programmed with code written and tested by professionals specifically for the chip. Not to mention PID licencing hassle.

Is there a market for pre-programmed MCUs? I think there is. I've seen a lot of high quality PCB designs incorporating either complete Teensy or bootloader chip + MCU. Whoever was able to pull that off will certainly be able to use NK20 chip alone and will appreciate space savings.
 
Last edited:
Kindly let me know once I program the teensy 3.2 can I run the code(same code forever) without MKL02?.
 
In a word, yes.

A more complete answer is: Once the bootloader has loaded your application into the MK20 flash (the "main" CPU), the MK20 is fully programmed, independent and self-starting. The bootloader is no longer involved until you explicitly request its help either by pressing the button or through a program request.

Several developers have implemented flash reprogramming for 'live" or wireless over-the-air updates. The bootloader is a separate device in the Teensy to ensure that the Teensy is essentially unbrickable. That's one half of Paul's magic sauce. The other half is the nearly ideal formfactor of the Teensy.
 
There has been at least one project around the forums designed to use a plug in MKL02 to flash a compact board. Unsure how successful the final project was but believe the 'make a one time programmable Teensy' part eventually worked.

Making a MK20 board that works is not trivial and there are many 'custom Teensy doesn't work' threads around. If going down this path would suggest having a look at:
http://www.appfruits.com/2015/03/building-your-own-custom-teensy/
https://www.pjrc.com/store/ic_mkl02.html

Way ahead would probably build a large scale prototype (make soldering as easy as you can) with onboard bootloader and cutable traces + pogo pin points and make sure it works (history suggests budgeting for three board spins to get to a working version), then on the same board cut the traces and try to program via a stand along bootloader chip. Then with a working large scale prototype step your size down without changeing the actual part values so you have something to compare with if you end up with wonky clock signals or other Rf or near field fun.

If you do PCB design for a living then apologies for telling you how to do your job.
 
I once made a MK20 board based on the T3.0 schematic with a removable 'programming stick' containing the preprogrammed TAN54 chip. It worked, but I didn't pursue the project any further. Volumes were too low to really justify a custom PCB, and imo PJRC deserves every penny from every Teensy sold. But still, it's possible and should work with the new MKL02 too.
 
Yes, everything is designed to be able to work without the bootloader chip, except of course uploading new code by USB.

While it's tempting to reduce costs as much as possible, you should probably design your PCB with the chip and probably populate it on the first few (presumably smaller) runs. That adds costs, but it's not nearly as expensive as having to replace lots of boards if there's some software/firmware issue. Almost all products end up having some sorts of issues that come up when lots of people start actually using the product. You can always switch to later leaving the place on the PCB unpopulated and get your HEX file programmed another way (like some distributors offer programming service).
 
Yes, everything is designed to be able to work without the bootloader chip, except of course uploading new code by USB.

I know this is an older post, but I was curious if anything need to be done for the MK20 to not look for the MKL04? Does a pull up resistor need to be added to the Reset pin on the MK20? Or can it just be set to HIGH in the script? Or just leave it alone once the script is uploaded...

Thanks
 
Status
Not open for further replies.
Back
Top