Port of Kinetis Bootloader KBOOT to K60 for UART?

[surrealist14]

Hi Folks,

I have seen a bit of interest elsewhere in the forum about obtaining a port of the Kinetis bootloader (KBOOT) to the K60 using a UART as the communications link.  At present, it appears to only support the TWR-K64 as probably the closest platform, but I'm not well versed in the differences between the two.

I am also a bit under the gun from a customer who is now insisting on a way to update firmware in the field.  I'm sure that with enough time and effort I can complete the port to the K60, but does anyone have a K60 version available already?  I unfortunately do not have the time to turn this into a research project, as fun as it might be!

Also, can anyone tell me what the difference is between KBOOT 1.2.0 and KBOOT 1.1.0?  Both are still available for download, but it is hard to tell whether one would be a better choice to port than the other.  If it make any difference, my application is using KSDK 1.1.  My project could not afford the additional time to port to KSDK 1.2 and then 1.3... <sigh>

The reference guide mentions getting the CMSIS header files from the microcontroller's product page, but I could not find these for the K60.  Maybe I just missed them?  What I am looking for specifically are the relevant K60 files to perform the porting activities described in the KBOOT reference manual.  Can someone provide a pointer to download these files or tell me where they can be found?

FYI, I am using version 7.40 of the IAR Embedded Workbench for Cortex-M for our development.

I also want to make sure that KBOOT is "bulletproof".  I know it needs to be flash-resident, and that some linker adjustments will be needed to correctly located my application alongside KBOOT, but would like to make sure that the bootloader is _always_ available, even if something goes wrong during a bootloader application update.  Does anyone have any hints on how to configure and run KBOOT so that even if the application is wiped, the bootloader will still be ready and waiting?  It seems like the potential for erasing all of the flash creates the potential to also wipe out the bootloader, which would leave me with a brain-dead system in the field.  Practical advice or experience in this area would be greatly appreciated!  It has to work, reliably, every time, even if the cord is unplugged or the power goes out.  We simply can't tolerate a non-functional system, so protecting the bootloader from accidental erasure is very important.

Thanks in advance for any help, and I will gladly share back anything learned from this effort.

Scott

[surrealist14]

Normally I would refrain from this type of posting, but I was extremely discouraged that I received NO useful responses from Freescale about a port for KBOOT for the K60.  After a lot of communication, my project decided to go with the uTasker Serial Loader from uTasker.com, in no small part because of the excellent and thorough responses that Mark Butcher provided to my initial question.

After configuring and using the uTasker Serial Loader now in a real K60 environment, I am pleased to let the community know that this is an excellent product, and was backed up by some of the best and most timely e-mail support I have ever received.  Although we went with the S-Record loader because S-Records are just so ubiquitous, this loader also supports the AN2295 format and the KBOOT format, if you really have your heart set on using those.

My project did not have a USB interface, SD card interface, or Ethernet interface, so it was a relatively simple matter of changing a single configuration file to turn these off, leaving just the serial interface enabled.  I also had to make a minor change to my application's linker configuration file for IAR, moving the application's vectors up to location 0x8000.  I also added some customization of I/O pins used to force entry into bootloader mode, very slight differences  from the TWR-K60D100M that the project used as a baseline.

I enabled write protection for the two blocks I reserved in K60 Flash for the bootloader (which we expect to be permanently resident), and then had to work around a problem with IAR where it would not allow any further downloading and debugging of that area after it had been programmed the first time.  This was solved after some discussion with Segger by using the Segger J-Link's flash loader instead of using IAR's flash loader, because I believe that the IAR flash loader is not permitting a mass erase of the Flash to unprotect the area of the bootloader, even though I specifically wanted to download and debug a new version.  Segger prompts you about the security, and in response to acknowledging a warning message, it will mass erase the flash so you can download and debug a different image.

Kudos to Mark Butcher for his thorough support and for producing a solid and versatile product at a very fair price.  It would still be very nice for Kinetis to get into the game, providing support for KBOOT for all of their processor families, if that is truly going to be their new standard bootloader.

My experiences were very positive, and for those who decide to go this route, I hope that yours are too.  I wanted to share this opinion with the community so that they would know that there is an alternative to doing a KBOOT port from some processor "close" to a K60.

Best of luck on your projects!

Scott

[mjbcswitzerland]

Scott

There is no real difference between Kboot 1.1.0 and 1.2.0 apart for the fact that 1.2.0 may support one or two more processors. Kboot 1.1.0 USB loading is not really usable due to a GUI bug which means that it takes around 6 minutes to load 100k of code. Kboot 1.2.0 GUI has this solved - no difference for UART loading between the two. The protocol is the same so 1.1.0 and 1.2.0 otherwise have no practical differences.

You can simply set a Flash block protection in the Flash configuration to ensure that the loader cannot be delected during operation (eg. by run-away application code). The boot loader always runs when there is no application and can be forced to start using various techniques (usually an input is used to force it but it can also be started by mailbox command from the application).

If you require a fully tested/guaranteed/supported/documented solution that works on all Kinetis devices and builds with all standard environents you can get this at the links below.

This includes K60 Kboot UART or USB-HID and also supports USB-MSD (as composite if desired at the same time as KBOOT) or UART SREC, or SD card or memory stick, or Ethernet/Web browser (mixed with each other as required and optionally with encryption for protecting code).

Builds with IAR7 (or KSDK, or IAR, or Keil or Green Hills etc.).

You can work with any application (including MQX, KSDK, Arduino, bare-metal, etc.) and it includes K60 simulation so that you can test the operation in (approx.) real time to test/review the code or develop custom extensions.

Regards

Mark

Kinetis: http://www.utasker.com/kinetis.html

K60: http://www.utasker.com/kinetis/TWR-K60N512.html / http://www.utasker.com/kinetis/TWR-K60D100M.html / http://www.utasker.com/kinetis/TWR-K60F120M.html

Serial Bootloader (Ethernet, USB, MSD, KBOOT, AN2295, SREC, SD-card): http://www.utasker.com/forum/index.php?topic=1873.msg6796#msg6796 / http://www.utasker.com/docs/uTasker/uTaskerSerialLoader.PDF

For the complete "out-of-the-box" Kinetis experience and faster time to market

:smileyinfo: Out-of-the-box boot loader support for 46 Kinetis boards, 8 modes and 10 IDEs (over 15'000 combinations from a single code source with no porting required)

[surrealist14]

Thank you for the information, Mark.  You clearly have done a lot of work in this area!

Just to be clear, uTasker _does_ require a fee for commercial use, correct?  Even if only interested in the bootloader and not in other uTasker features?

While I would not try to prevent anyone from earning an honest living, it is a little disconcerting to have to buy a port for the K60 when Freescale offers ports for other Kinetis family members for free.

I remain hopeful that someone has ported KBOOT to the K60, and that they will be willing to share it with the community, although I certainly have not ruled out the solution you suggest.

Sincere thanks for your help and input!

Scott

[mjbcswitzerland]

Hi Scott

For commerical users of just the serial loader project a 50% discount applies. This means that a commercial project costs $242.50 for a product with unlimited quantity (royalty-free) and 3 months email and telephone support (toll-free).

Included are ready-to-use loaders (many popular ones beyond the KBOOT compatible ones that can be mixed and matched as required - far beyond the present Freescale offering) for almost all Freescale devices, almost all IDEs and all has been extensively tested and documented so that there is little work for users with regard to integration, documentation, SW audits or support if ever needed. Usually the total cost of ownership turns out to be much less that free code, even if no porting is required on the way (which can turn out to be many times more expensive, even of an open-source port turns up somewhere, and risk project deadlines).

The uTasker Serial Loader (which will also work with Coldfires) covers a requirement for cases where Freescale doesn't have a particular port ready or no support for various techniques that are often requested (Kboot is very rarely used [at the moment by real projects] for field programming of K60s - more popular and usually more convenient are SREC, USB-MSD, SD-card and Ethernet loading).

Why Freescale doesn't support a complete set of devices is something to discuss with Freescale [I suspect that the expense would be prohibitive] (maybe they will put someone on the job if you shout loudly enough ;-) ) but the uTasker solution is a full-time-professional program which could not be possible without a small amount of commerical funding (Freescale doesn't fund it in any way), whereby Freescale users should not forget that they do ultimately fund the 'free' software through chip prices (because the Freescale developers probably don't come in to work for free).

For companies who can't afford any costs there is a start-up program where the fee is not required until after a year of selling the product.

Regards

Mark

[surrealist14]

Hi Mark,

I certainly see the value in your offering, and understand that we all have to pay the bills.  It would be nice to work on projects simply out of kindness, but that only goes so far!

Given that I have a working K60 application using a design that was derived from the K60 tower, how long do you think it would take to rework my project so that it links in the proper locations and includes your serial bootloader?  I know the linker file will have to change, but I'm not sure what else would be required.  Most likely the range over which I calculate my application's CRC would change as well, since the starting address of the application will no longer be 0x00000000.

I ask this because I know that's exactly what my management is going to ask.  In other words, I'm hoping for a bit of help in justifying the cost vs. benefit is in order to help me convince my management that this is a viable way to go, and will be less expensive than trying to modify a K64 KBOOT project to run on a K60 instead.

Your help is greatly appreciated, and I do think that you have addressed a need that unfortunately Freescale has yet to fill.  Having so many processor variants makes it tough to provide the same level of tool support to all variants, and as you point out, they are not doing it for free.

Kindest regards and many thanks.  Your thoughts on the level of effort to convert my existing project to one that can coexist with the bootloader would be greatly appreciated.  We could even arrange a phone call to discuss if that would be easier.

Scott

[mjbcswitzerland]

Scott

There is a list of things to consider here

http://www.utasker.com/forum/index.php?topic=1866.0

If you have a well designed software you will only need to change the link address for it to work with a serial loader. [If running interrupt vectors from Flash VTOR needs to be adjusted if the framework doesn't already do this automatically]

In some MQX based SW it has been found that the application gets stuck in the application's clock initialisation (the code assumes that the clock is in its reset state and can't handle the case when a boot loader has already configured it for its own use) but this is easy to solve by just removing the clock initialisation since the boot loader has alread done it.

Most difficulties tedn to be experienced by PE users because PE will tend to overwrite things like linker script settings but these are all solvable with a bit of study of the PE workings/settings.

Potential difficulties are not loader specific but of general nature and so have to be solved for whatever boot loader is chosen.

There are uTasker application references for each board - one that works standalone (linked to 0x00000000) and one that works with a boot loader (linked to 0x8080 as convention so that all are compatible but can be any address higher than the physically loader used). The 'only' difference is the linker script file used - there are linker scripts for all boards for both cases in the uTasker package. I have attached, as reference, the two used for standalone and boot loadable for 512k Flash/128 SRAM (IAR7) case.

Note that if you require a completely free serial loader for the K60 you can also consider the Freescale AN2295 (there is also an option in the uTasker loader for this) because they distribute it with an IAR project for the K60 (if it matches your UART you may get away with little work); it is available in two different versions but I never found documentation (and documentation doesn't fully match the actual code so one needs to read-between-the-lines and check the source) for both so you may need to clear up its version management since there is little formal organisation. You will however also need to check that your customer is happy with it because it is DOS based and quite strange to use (lots of typing and switching on the board at the correct time when the program is expecting it) - my experience is that end users prefer OS independent solutions with a simple drag-and-drop user interface. KBoot in fact requires the user to install about 1/2G byte of Microsoft framework SW before it starts....so you will also need to check that it is actually acceptable for your case. It isn't drag and drop and requires several configurations steps and clicks so is also not particularly practical for production work.

[Personally I prefer SREC UART loading because the user doesn't need to install SW, it is easy to use but it can operate using drag-and-drop. It also allows a very small boot loader code size]

Regards

Mark

[surrealist14]

Hi Mark,

Thank you once again for the very detailed and complete answer.  I have a "bare-metal" applications that makes use of the KSDK 1.1, but doesn't do anything terribly fancy after that.  There is an initial CRC check, so I would have to modify the range over which the application CRC is calculated, and of course change the application location.

I do not have my schematics with me, but I believe that I might need to change the default UART that is being used.  It uses an FTDI RS-232 to USB converter, which looks like a COM port to Windows, and a straight UART to the K60, but allows a USB cable connection to the target.  So, the SREC loader with drag 'n drop functionality that you mention sounds like a good potential option, and the relatively low cost of your solution could also significantly reduce overall porting time.

Can you tell me how I can go about downloading an evaluation copy to try out, along with the relevant documentation on porting and adaptation of my existing application code to work with your serial bootloader?  I will present the options you described tomorrow, and assuming that we get the go-ahead from our customer, I expect that we will select a course of action very promptly.

Your help has been extremely professional and thorough, and seems like an attractive option that I will give full and complete consideration to.  Thank you sincerely for the time and effort you have put into answering my questions.

Best regards!

Scott

[mjbcswitzerland]

Scott

There is a publicly available version at http://www.utasker.com/forum/index.php?topic=1721.msg6697#msg6697 which can be freely downloaded (project state summer 2014 and not supported).

If you prefer to use the most-up-to-date code (with all new processor and loading protocol features and support), with 30 day free support evaluation you can register at http://www.utasker.com/Licensing/request.html

The 'porting guide' is included in http://www.utasker.com/docs/uTasker/uTaskerSerialLoader.PDF although "porting" is a bit exaggerated since the project doesn't work like that - it adapts itself automatically to board and processor so it is more a configuration that is required. If you use VisualStudio 2010 Express (free) [or a full version] you can also run the project in the uTasker Kinetis simulator and test operation as if it were a real board (also verify the UART and pins used).

You can select any UART that you want to use with (eg.)

#define LOADER_UART           3 // used by standard TWR-K60N512 tower with TWR-SER2 card (or 5 with virtual COM port connection)

(where 0..5 is possible on the K60).

If your HW connection is not on the default Mux pins there are various alternatives available that can be selected instead:

//#define UART0_A_LOW                                             // alternative UART0 pin mapping

//#define UART0_ON_B                                               // alternative UART0 pin mapping

//#define UART0_ON_D                                               // alternative UART0 pin mapping

//#define UART1_ON_C                                               // alternative UART1 pin mapping (default is on port E)

//#define UART2_ON_E                                               // alternative UART2 pin mapping on port E (default is on port D)

//#define UART2_ON_F                                               // alternative UART2 pin mapping on port F (default is on port D)

//#define UART3_ON_B                                               // alternative UART3 pin mapping

//#define UART3_ON_F                                               // alternative UART3 pin mapping on port F

  #define UART3_ON_C                                               // alternative UART3 pin mapping

//#define UART4_ON_C                                               // alternative UART4 pin mapping

//#define UART5_ON_D                                               // alternative UART5 pin mapping

If you don't use the typical 50MHz oscillator input (as used by most K60 designs) there is a similar section where the crystal and mode can be seleted, as well as the core, bus, flash speeds can be set (run in simulator to check that it is correct and it will tell you the speed used and warn in case anything is out-of-spec for the device).

Just search for the board that your HW is most similar to and then make any adjustments as needed.

Regards

Mark