[K20D50M]: Looking for a simple USB bootloader for K20DX128VFM5

[huishao2]

Hi-

My existing product needs adding bootloader for image update purpose only. There is only one USB interface on it so I think it makes sense to use USB to receive/update FW image from PC as host. My app size is around 60KB and hope bootloader won't take too much memory.

Product uses K20DX128VFM5 MCU and development GUI is IAR only.

I went through AN4370SW but not sure if it can be used as straight forward as one to K20DX128VFM5, or any porting guideline including app vector table redirection exists?

Thanks!

Hui

[huishao2]

Hi Mark,

Thanks for suggestion of using MSD, it is good idea to bypass PC utility.

My board is clocked by 8MHz crystal, seems like both TWR and FRDM are fine.

I have further questions here, please advise:

[1] In app_hw_kinetis.h, there is TWR_K20N50M; in config.h, there is TWR_K20D50M, what is the difference between the two TWRs? How do I enable TWR_K20N50M which is not in config.h?

[2]When I enable USB_INTERFACE, do USB_MSD device, USB_HID, KBOOT_HID get enabled together?

[3] Is OSC_LOW_GAIN_MODE  not supported for TWR_K20D50M or TWR_K20N50M? My board doesn't support High Gain anyway.

[4] Tried building the project and noticed that the obj files contain eth_drv.o, Ethernet.o, http.o, ip.o, tcp.o, arp.o ... do I need those Ethernet related stuff? I don't have Ethernet interface on my board.

[5] In IAR Workspace, there are two options: FLASH/RAM, what does it mean? If want to make debug/release build, how do I proceed?

Thanks!

Hui

[mjbcswitzerland]

Hui

1. In app_hw_kinetis.h all references should be TWR_K20D50M. I just checked in a correction (the name probably changed in the main project and this wasn't modified in the loader) where I renamed it properly.

2. USB_INTERFACE enables the (generic) USB interface. You then define whether you want USB_MSD device or other classes. You need to set USB_MSD_DEVICE_LOADER in addition to USB_INTERFACE).
It is possible to set multiple USB class types and it will result in a composite device with multiple loader methods, but it will also result in more code - so just use one.

3. The FRDM board needs OSC_LOW_GAIN_MODE since its circuit has no loading.
The TWR board must not use OSC_LOW_GAIN_MODE since it needs high gain mode because its crystal circuit has loading components.
You chose this depending on your board's circuit. If it doesn't start, try the inverse.

4. The project dynamically configures itself for any board. All objects are built but everything to do with Ethernet and other unused things will be empty.
Don't remove any files because it won't change the result and won't save any space (it will just make the project incompatible in case you later want to use a different board that needs the parts that are no longer there).

5. Use the FLASH build. The RAM build is for loading to RAM for debugging but isn't possible on the K20 with only 16k SRAM anyway. The resulting object can be programmed to the Flash and allows the board to boot.

Regards

Mark

[huishao2]

Hi Mark,

I downloaded zip file from Development branch, hope it is stable.

I tried Build and Download from IAR and got errors like:

Thu Apr 27, 2017 10:29:31: Verification error at 0x0000040C: mem = 0xFE, file = 0xBE
Thu Apr 27, 2017 10:29:31: SWO: Manchester, CPU clock = 72000kHz, Auto divider = 4
Thu Apr 27, 2017 10:29:31: Warning: Cannot measure current when I-jet is not powering the target.
Thu Apr 27, 2017 10:29:31: Download completed but verification failed.

The memory 0x40C above is for Flash Configuration and not supposed to be touched in my case. Why does flash loader touches that area? It is because of problem in K_128_16.icf file or .board file used? I am using FlashKx0Dxxx16K1K.board from IAR, same as the one used for my main application.

Looking into Memory, the contents on address 0x400 are "00 00 00 00 00 00 00 00 ff ff ff ff be 07 ff ff". Seems to match 0xBE as  expected.

thanks!

Hui

[mjbcswitzerland]

Hui

The Flash configuration is defined in app_hw_kinetis.h:
eg.

    #define KINETIS_FLASH_CONFIGURATION_BACKDOOR_KEY       {BACKDOOR_KEY_0, BACKDOOR_KEY_1, BACKDOOR_KEY_2, BACKDOOR_KEY_3, BACKDOOR_KEY_4, BACKDOOR_KEY_5, BACKDOOR_KEY_6, BACKDOOR_KEY_7}
    #define KINETIS_FLASH_CONFIGURATION_PROGRAM_PROTECTION (0xffffffff)  // PROT[31:24]:PROT[23:16]:PROT[15:8]:PROT[7:0] - no protection when all are '1'
    #define KINETIS_FLASH_CONFIGURATION_SECURITY           (FTFL_FSEC_SEC_UNSECURE | FTFL_FSEC_FSLACC_GRANTED | FTFL_FSEC_MEEN_ENABLED | FTFL_FSEC_KEYEN_ENABLED)
    #define KINETIS_FLASH_CONFIGURATION_NONVOL_OPTION      (FTFL_FOPT_EZPORT_ENABLED | FTFL_FOPT_LPBOOT_NORMAL | FTFL_FOPT_NMI_ENABLED)

It is the bootloader which defines this since it occupies the first sector of flash. The values are programmed when the code is loaded.

IAR's debugger will try to protect against values in the security byte that could cause debugger to be disabled. The warning means that it didn't program the exact value that is in the file but it is not a problem - it is just a warning that the programmed value differs.
You can also change the defines as required in case you want code protection later.

Regards

Mark

[huishao2]

Hi Mark,

Then what is the proper way to solve the IAR issue? By changing KINETIS_FLASH_CONFIGURATION_SECURITY to enable backdoor (0xFE, unsecured)? Or other better ways.

Currently I unchecked the Verify for image downloading to bypass the verification error. Also I disabled watchdog and forced it stay in bootloader mode by doing things below:

#define WATCHDOG_DISABLE() 1 //(_READ_PORT_MASK(E, SWITCH_2) == 0) // pull this input down to disable watchdog

#define FORCE_BOOT() 1 //(_READ_PORT_MASK(E, SWITCH_1) == 0) // pull this input down to force boot loader mode

What I saw is “USB Driver D:” show up in my Windows 10. However, it is gone soon after Windows did a scan. What is the reason for that?

Thanks and regards,

Hui

[mjbcswitzerland]

Hui

The IAR warning is not an issue but if you prefer to remove it you could try

#define KINETIS_FLASH_CONFIGURATION_SECURITY 0xfe (or whatever value IAR prefers to see).

You have correctly disabled the watchdog and forced the loader on every start. However I don't know why the the drive disappears after some time - it should stay forever. I would use the debugger and pause it when the disc disappears to see whether you can see a fault. If possible, connect the heart-beat output to an LED (it flashes at 5Hz when all is working OK) so that it is easy to see in case the board stops operating correctly. [see #define BLINK_LED to attach it to a specific output]

Regards

Mark

[huishao2]

Hi Mark,

I fixed the disappearing D driver issue by restoring

define symbol __ICFEDIT_region_RAM_start__ = 0x1fffe1f0;

Previously I modified line above in .icf file to match K20D50M RAM start address which is 0x1FFFE000 but it seems to be a problem.

Question to it, why does the linker file skip the RAM start address by 0x1F0? Reserved for vector table?

And, in loader.h:

        #define UTASKER_APP_START     (32 * 1024)                        // application starts at this address
        #define INTERMEDIATE_PROG_BUFFER  (8 * 1024)                     // when UART speed greater than 57600 Baud is used an intermediate buffer is recommended
        #define UTASKER_APP_END       (unsigned char *)(UTASKER_APP_START + (100 * 1024)) // end of application space - after maximum application size

If the app start address is 32KB, then UTASKER_APP_END is actually 132KB which is beyond 128KB Flash end of K20D50M.

thanks!

Hui

[mjbcswitzerland]

Hi

1. The linker script's RAM reserves space for interrupt vectors in RAM at the start of the memory. If you remove this variables and interrupt vectors will overwrite each other and so serious corruption can take place. All linker scripts should be correct so it is best not to change them.

2. The values for the start of application and maximum size need to be suitable for the physical sizes available (which may change with device types). It is correct that 100k application would be too much for a 128k part when the application starts at 32k. Most devices are set up suitably but there may be exceptions as different derivations are used for time to time. Also, if there are areas of Flash used by the application for storing parameters and such, these should be considered so that they are preserved during firmware updates.

Do you now have complete functionality? How do you rate the solution as boot loader?

Regards

Mark

[huishao2]

Hi Mark,

If we deploy this USB-MSD bootloader to our product, do we have to pay royalty fee or licensing fee? And what kind of support do we expect to have?

Thanks!

Hui

[mjbcswitzerland]

Hi

Full details about licensing and support options are at
http://www.utasker.com/kinetis.html

Basically you can choose to use it free without guarantee, or license its use in a single or unlimited products (all options royalty-free) which includes professional support (email/telephone) if and when needed during 3 or 12 months. The licensing fee is essentially to ensure that you have fast professional help in case needed and also helps fund the project development.

Regards

Mark

[huishao2]

Hi Mark,

Yes I have tried downloading a bin file and made it work as expected. I spent a few days enabling AN4370 bootloader which is not as simple as this MSD one in terms of normal use. The former one needs two types of drivers installed for run-time and DFU modes respectively, and larger footprint and PC utility.

Thanks!

Hui

[mjbcswitzerland]

Hi

There are various boot loaders for your device at
http://www.utasker.com/kinetis/FRDM-K20D50M.html
http://www.utasker.com/kinetis/TWR-K20D50M.html

Choices and documentation:
http://www.utasker.com/docs/uTasker/uTaskerSerialLoader.PDF
http://www.utasker.com/docs/uTasker/uTasker_BM_Loader.pdf

Open source version available on GITHUB:
Web:      https://github.com/uTasker/uTasker-Kinetis
HTTPS:    https://github.com/uTasker/uTasker-Kinetis.git
SSH:      git@github.com:uTasker/uTasker-Kinetis.git

Requires no porting, works out-of-the-box with IAR, and professional support available if needed.

Regards

Mark

[huishao2]

Hi Mark,

Thanks for your reply.

For my application case, I have only USB interface so I assume USB-HID is the proper way for me.

In config.h, which reference platform should I choose? TWR_K20D50M or FRDM_K20D50M?

How should I enable following macros from doc "μTasker – Serial Loader User’s Guide":

#define USB_INTERFACE

#define HID_LOADER

For IAR Debugger->Download, which flash loader should I select?

Thanks and regards

Hui

[mjbcswitzerland]

Hui

For IAR use the project:

\Applications\uTaskerSerialBoot\IAR7_Kinetis\uTaskerSerialBoot.eww

In general options set the processor type.
Set the linker script to suit your device (probably K_128_16.icf)

In config.h select FRDM_K20D50M or TWR_K20D50M depending on which best matches your board (you may need to adjust a clock setting if you have different crystals). Search app_hw_kinetis.h for the board define to see the settings specific to it and modify if you see fit. Both FRDM and TWR boards use an 8MHz crystal so it may not be critical.
Depending on the crystal circuit you may or may not need #define OSC_LOW_GAIN_MODE // oscillator without feedback resistor or load capacitors so use low gain mode (if set wrong the crystal may not start oscillating)

For USB only, disable SERIAL_INTERFACE and enable USB_INTERFACE
I would use the variation USB_MSD_DEVICE_LOADER (doesn't need any special PC program such as KBOOT).

The output is in
\Applications\uTaskerSerialBoot\IAR7_Kinetis\FLASH\Exe
uTaskerSerialBoot.bin (and uTaskerSerialBoot.out)

and is about 16k in size.

Regards

Mark