Kinetis Boot Loader for SREC UART, SD Card and USB-MSD loading

[mjbcswitzerland]

Hi All

There has always been a high demand for boot loader solutions and the uTasker project includes a number of these which have proven to be quite popular, even for use with applications from different sources.

The demands as to how the loader operates are quite varied and so a flexible loader has been put together which allows the following modes of boot loader operation in one single loader:

- UART S-REC loading at 115200 Baud

- SD Card loading (a new software is copied to an SD card and inserted)

- USB-MSD (the board apears as a disk drive and the software can be copied)

This allows all of the three possibilites to be used in a compatible manner. The boot loader size (with all modes enabled together) is about 25k. If some modes are not required they can be mixed as necessary in the project and so much smaller Flash size needed.

For K60 Tower Kit users there is a package at µTasker Test Software and Demos which allows it to be used immediately for any application up to 130k in size. The loader is documented at http://www.utasker.com/docs/uTasker/uTaskerSerialLoader.PDF and there is also a video showing its flexible operation at Kinetis K60 Tower Kit - Flexible Boot Loader - YouTube

Note that the complete package also supports encryption (to allow code distribution without reverse enginering possibility), USB-DFU, HS-USB and Ethernet loader (Web Server based - about 18k Flash) for chips with Ethernet.

Regards

Mark

[luishs]

Hello Mark.

What configuration should I choose to work with MK20DN512VLK10  and MK20DN512VLL10 ?.
Or if I must to do a custom configuration in config.h and app_hw_kinetis.h

Unfortunately they are the only Kinetis, apart from the MK66, that I have found in stock. I would have preferred to use the MK64 or MK24, but I can not find it anywhere, sold out everywhere and with a delivery date of December 2018 (this is outrageous).

Regards. 

[mjbcswitzerland]

Luis

For a K20DN512 part you can use a K60DN512 configuration (eg. TWR-K60D100M) - just don't enable Ethernet.
Ref: http://www.utasker.com/kinetis/TWR-K60D100M.html

Regards

Mark

[luishs]

Thanks mark.

I have looked at the configuration, but it seems that this board K60D100M works with an external clock of 50Mhz, I do not use it for my designs, I always connect a 16Mhz quartz to use the internal microcontroller clock

Regards

[mjbcswitzerland]

Luis

To use 16MHz crystal instead of 50MHz oscillator change the clock settings from:

#define EXTERNAL_CLOCK       50000000    // this must be 50MHz in order to use Ethernet in RMII mode
#define _EXTERNAL_CLOCK      EXTERNAL_CLOCK

#define CLOCK_DIV        25 // input must be divided to 2MHz..4MHz range (/1 to /25 possible)
#define CLOCK_MUL      48 // the PLL multiplication factor to achieve operating frequency of 96MHz (x24 to x55 possible)

to

#define CRYSTAL_FREQUENCY    16000000    // 16 MHz crystal
#define _EXTERNAL_CLOCK      CRYSTAL_FREQUENCY
#define CLOCK_DIV        8 // input must be divided to 2MHz..4MHz range (/1 to /25 possible)

#define CLOCK_MUL      48 // the PLL multiplication factor to achieve operating frequency of 96MHz (x24 to x55 possible)

for 96Mhz PLL (suitable for USB), 48Mz bus and 24MHz Flash.

Regards

Mark

[luishs]

Ok, thank you Mark, I will check.

Regards

[luishs]

Hello Mark.

After the success with your SD bootloader in Kinetis, I tried to do the same for STM32, I have some questions please:

1.- Not available to use the project in Eclipse ?, I have opened it with Coocox, but I prefer Eclipse if possible.
2.- I want to use for an STM32F405 or STM32F407 with bootloader from SD card by SDIO. It's correct if I choose ST_MB997A_DISCOVERY ?, The SD will not be for SPI, but for SDIO, I'm not sure how select it.

3.- What is the parameter I must configure to enable bootloader from SD card ?. need force boot and not retain loader to enter in boot mode without switches and SD socket with no sd card switch detect.

4.- In config.h I have enable  SDCARD_SUPPORT, but when I go to app_hw_stm32.h  the  "#if defined SDCARD_SUPPORT" is dissabled. What may be the problem ?.

5.- With this bootloader for STM32, the user application must compile also to start in 0x8000 or what is the correct start address for STM32 ?.

6.- There is no "#define DELETE_SDCARD_FILE_AFTER_UPDATE" to allow delete firmware automatically after load ?.

Best regards.

[mjbcswitzerland]

Hi Luis

Since this is not a Kinetis question I recommend asking it in the uTasker forum.

As you may know, the uTasker project was originally developed as a small-footprint TCP/IP stack (with FTP, Web Server etc.) for the MC9S12NE64 which was a 16 bit HC12 processor from Freescale with 64k of internal Flash (in two banks that needed to be swapped between in operation) and 16k of SRAM (if I remember correctly), and internal 10/100Mb/s Ethernet and PHY. This was in 2004. It then moved to support the Coldfire V2 parts, some of which also had the internal Ethernet/PHY, which was well used until about 2012 when the Kinetis more of less took over from them. In the meantime it's capabilities had been continuously extended, including USB stack, utFAT and Modbus, among others (and its popular boot loader features).

It was also ported to other NXP processor families (LPC2xxx, LPC17xx), Atmel (SAM7, AVR32), Stellaris and STM32, but it is the Kinetis parts that presently are focused on. Some may suggest that supporting other devices is not good for the Kinetis project but this is not at all true. Since users can move between these parts with almost no effort the strategy has greatly benefited the NXP parts since in many cases users of other families could start with what they already knew and then very easily move their projects (and subsequent products) to the Coldfire or Kinetis parts with some gentle persuasion and convincing that this was the best thing for them. The net flow to Kinetis has resulted in an interesting gain in customers for Freescale/NXP who may otherwise never have taken the step!

Regards

Mark

P.S. Note that CooCox is in fact Eclipse based.... it just has a different feel to it. You can also use CooCox for your Kinetis work if you want!

[luishs]

Ok, thank you Mark.

I have open a post in the STM32 forum.  May you help me please ? 

STM32F405/407VGT6 Bootloader Configuration 

Kind Regards

[mjbcswitzerland]

Hi All

Note that the serial loader has been updated to include MODBUS slave support (ASCII or RTU), including semi-duplex RS485. This allows a network of devices to have their firmware updated by a Modbus master using simple holding register block writes (to individual slaves or by broadcast to all). [The internal Flash can optionally be observed by input register reads].

Almost all Kinetis parts are supported (K, KL, KE, KEA, KV etc.) on any UART (or LPUART).

The complete operation can be simply tested in real time in the uTasker Kinetis simulator so even customisation is very simple and efficient....

The user's guide will shortly be extended with full details.

The boot loader's size is less that 10k Flash.

Regards

Mark

P.S. The Modbus operation is not available in the Open Source version but this capability makes it easy for any existing professional Kinetis projects (or ones in development) that are Modbus oriented to add a Modbus slave update capability.
It can be built immediately for almost any part in almost any IDE (KDS, MCUXpressor, S32 Developer's Studio,IAR, Keil, Atollic, Rowley, CooCox, Green Hills, etc...).

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

[luishs]

Hello Mark.

It's possible configure uTaskter Bootloader to work with Kinetis MK64FX512VLL12 with 16 Mhz crystal ??

I configured already with success to work with MK66 based on FRDM-K66, only I needed to modify crystal frequency to 16Mhz, because it was for a custom board.

About the MK64, I checked the FRDM-K64 schematic, and it does not install a crystal for the oscillator, but it gets a 50Mhz signal from a Phy Ethernet chip. I need to configure uTaskter for my MK64 with 16Mhz crystal.

I can try to do it with the Teensy 3.5 configuration (if available), but I already had problems with the Teensy 3.6 configuration, and for my MK66 board, I finally used FRDM-K66 with minor modifications to the crystal frequency setting.

May you help me, please, to configure uTastker Bootloader for a MK64FX512VLL12 with 16Mhz crystal ?.

Thank you and kind regards.

[mjbcswitzerland]

Hi Luis

You can use this setup (same as TEENSY_3_5):

        #define CRYSTAL_FREQUENCY    16000000    // 16 MHz crystal
        #define OSC_LOW_GAIN_MODE  // <- assuming nocrystal loading components
        #define _EXTERNAL_CLOCK      CRYSTAL_FREQUENCY
        #define CLOCK_DIV            4   // input must be divided to 2MHz..4MHz range (/1 to /24)
        #define CLOCK_MUL            30  // the PLL multiplication factor to achieve operating frequency of 120MHz (x24 to x55 possible)
        #define FLEX_CLOCK_DIVIDE    3   // 120/3 to give 40MHz
        #define FLASH_CLOCK_DIVIDE   5   // 120/5 to give 24MHz

This will give 120MHz core, 60MHz bus and 24MHz flash clocks.

If using USB you can choose from

  //#define USB_CRYSTAL_LESS             // use 48MHz IRC as USB source (according to Freescale AN4905 - only possible in device mode)
    #define USB_CLOCK_GENERATED_INTERNALLY // use USB clock from internal source rather than external pin - 120MHz is suitable from PLL

Regards

Mark

[luishs]

Thanks Mark.

But I have problems. With Teensy 3.5, the Led blink but does not load anything, and with the FRD-K64 the LED does not blink or lit and it does not work. I'll try to work with FRD-K66 configuration, to see if simply changing the PLL configuration can work.

With Teensy 3.5, sometimes the firmware is loaded but fails and crashes, and most of the time nothing is loaded, just the led flashes. My only current option is to try to work with the FRD-K66 configuration, and modify it for MK64, this configuration works with my Teensy 3.6 and custom board with MK66. So I think I simply need to change PLL settings to run at 120Mhz instead of 180Mhz, the rest of the features I think are the same for MK64 or MK66 compilation, and it probably does not even need to change the Linker Script for a program so small.

Kind Regards

[mjbcswitzerland]

Luis

If the Teensy 3.5 LED blinks (5Hz) it means that it is running (i.e. the clock setup is OK). In case of problems with actual loading, the issue will probably be elsewhere - which loader type are you using?

The FRDM-K64F has a 50MHz oscillator and so can't use the 16MHz crystal setup - it will not start with this.

Regards

Mark

[luishs]

Hello again Mark.

II'm going crazy, this is like a nightmare. After to do many tests, I think finally I have detect the problem, but I do not know why it happens and how to fix it.

I detect that bootloader never loads firmware for small programs (10K to 24K tested) and loads with larger programs (tested with a program size of 67K).

I have read this in your source code, in loader.h:

#define CODE_OFFSET     0xc298  // ensure that this value is a multiple of the smallest flash programming entity size (divisible by 8 is suitable for all Kinetis parts)

May be this is the problem, configure correctly CODE_OFFSET to work with small programs ?

If this is the problem, how may I calculate CODE_OFFSET to avoid this problem with small firmware programs ?.

Kind Regards and thanks for you support.

[mjbcswitzerland]

Luis

CODE_OFFSET is used by the encryption/decryption algorithm for the SD c a r d loader, therefore I deduce that you are using this method.

I am not aware of a problem with this at the moment but if you post a binary file that fails (I assume you use the default authentication/encryption settings - post any changed settings so that I can use them) I can test it in order to identify whether it is this.

Regards

Mark

[luishs]

Ok, thanks Mark.

I have upload test files to this MEGA link
https://mega.nz/#!8BtVxZZI!8tO9Dt2YNTyi2PiDEQQW-1ABBSO061_YfjTeIu4gZ3c

This RAR include:
1.- TEST_LEDS_Teensy35_0x8000.hex, the file compiled with start address 0x8000
2.- prueba.hex, same than before to encrypt with TEST.bat
3.- TEST.bat, a bat file that convert HEX to BIN and encrypt with uTaskerConvert.exe
4.- testcryp.bin, the encripted file that bootloader must load, but fail because its small 10K size.

For this test, I have apply all default values from your source code, so in TEST.bat:
objcopy --input-target=ihex --output-target=binary prueba.hex prueba.bin
uTaskerConvert.exe prueba.bin testcryp.bin -0x1235 -b748b6531124 -ff25a788f2e681338777 0xafe1 -c298
del prueba.bin

[mjbcswitzerland]

Hi Luis

Note that the syntax for the encryption should be

uTaskerConvert.exe prueba.bin testcryp.bin -0x1235 -b748b6531124 -ff25a788f2e681338777 -afe1 -c298

rather than

uTaskerConvert.exe prueba.bin testcryp.bin -0x1235 -b748b6531124 -ff25a788f2e681338777 0xafe1 -c298

although I expect that this is a typo rather than what you are using in the bat file (?) [like this the code will never be recognised because its coding then deviates from the boot loaders set of keys]

However, I could also reproduce the problem and have corrected the code in "disk_loader.c". With the correction I was then getting an exact decrypted image in flash.

The file is checked in on GIT hub and I have also attached it here - if you overwrite the previous version you can verify that it solves the issue when using the encrypted mode and your upload file.

Good luck

Regards

Mark

[luishs]

Hello Mark.

I've check your update, and although it looks like it now loads the firmware, it does not run and crashes after the upload.

If I had bad 0xafe1 in my bat file, but after correcting it has not solved the problem either.

I have to send a board with the bootloader today, I will add non-useful source code to increase the size of the binary artificially. It seems like this if it loads when the binary passes a certain size, in my tests starting at 67K.

Kind Regards

[luishs]

Well, seems finally works, but the afe1 code only works without the 0x prefix (0xafe1 fails), I added it like you said and then fail. So, I was a bit confused about the 0x prefix in code to encrypt and I have check all combinations with the two last codes used in uTaskConvert with encryption.

According with my tests, only works is last two codes do not include the 0x prefix. So in my before example this is that works now:

uTaskerConvert.exe prueba.bin testcryp.bin -0x1235 -b748b6531124 -ff25a788f2e681338777 -afe1 -c298

and this fails:

uTaskerConvert.exe prueba.bin testcryp.bin -0x1235 -b748b6531124 -ff25a788f2e681338777 0xafe1 -c298

If have check to put 0x prefix to both last codes and fail, also any of both codes with 0x prefix also fail. Well, now seems all run perfectly. Thank you very much Mark.

Kind Regards

[mjbcswitzerland]

Luis

The arguments for the encryption parameters need to be "-XXXX" and then you should have no problems. The program simply parses each argument found by removing the first letter (the '-') and then converting the string into a 16 bit value -afe1 will then be (internally) 0xafe1.

If however 0xafe1 is used it will convert "xafe1" which happens to result in 0x1afe (as calculated by its internal conversion) and the setting at the boot loader would need to be 0x1afe to be able to decrypt the content!

These are details of the way that "uTaskerConvert.exe" operates which may explain some difficulties if you were not using the exact syntax. For some reason the magic number is supplied as 0xXXXX, but this will be historic since the encryption was added at a later date (it it at V1.10 today).

Regards

Mark