K22 Remote Firmware Update

[burgeh]

Greetings,

I am currently using the MK22FN256VLH12 micro controller on a custom board with KDS v3.2 and Processor Expert.

I currently am able to use a bootloader and update the chip via USB with the KinetisFlashTool to update the application code. I am wondering what the process looks like or if there is a reference I can use that would demonstrate the process to update my application code remotely.

For example I receive data through UART, that data is the binary file of the new application code, am I able to load that application code onto the controller to update it?

Thanks!

[burgeh]

Mark, Alex

Thanks for the quick response! My general purpose would be to upload firmware updates over the air, either via bluetooth or through cell modem (both communicate through UART). I have some non-volatile memory as well I could use in a pinch.

Mark your method of using a POST command via Http and having the controller read that and use it would be very useful and similar to what I would like to use. It seems that this is all setup via the Utasker bootloader. However, I would like to not be in that area of operation. I would prefer something in the application code that it could handle this, such as look for a flag in the POST and if so enter an interrupt to update the application code.

Thoughts?

[mjbcswitzerland]

Christopher

If you are receiving the update over the air and have all of the drivers and protocols in place to communicate it is simplest if your application can accept a binary file and save it to a defined area in internal Flash or in SPI flash (or onto an SD card if you use one in the product).

You can then reset to either the uTasker "Bare-Minimum" loader (2..4k in size), which will then copy from internal or SPI flash in a fail safe manner and reboot to the new application. This loader also supports encrypted applications so you can also update code without any risk of it being copied by anyone intercepting it. The only drawback if using internal Flash is that you need ample space for the original application AND the new one before the copy takes place.

If you have an SD card you can save the new firmware to it and boot to the uTasker SD card serial loader which then updates the application from its image. Again authenticated and encrypted application content is supported. The SD card serial loader needs more space (I think about 12k..16k) due to the fact that it has additional FAT overhead.

[Same is true in case you had a memory stick on USB in the product, which is however much less likely... since the uTasker SD card loader will also work on USB with a memory stick].

Regards

Mark

[burgeh]

mjbcswitzerland‌

You mentioned "If you have used the USB mode with Kboot you can also use its UART mode to do updates." I am using the towerboot loader that is used in the basic KBOOT v2 files for the MK22FN256VLH. Do you know where I could find this more?

Your "uTaskerSerialBoot_FRDM-K22F_KBOOT_HID_UART_MSD.bin "  loaded at link address 0x8080 my current setup using KBOOT for my application is as shown. So instead of 0xA000 it should be 0x8080. then m_text would be 0x8490 and size would be 0x37B70 correct?

[mjbcswitzerland]

Christopher

I expect that the USB and UART loaders are in the same SW package but don't have any further details.

To work with the uTasker version that you mention the vectors can be linked to 0x8080 and m_text to 0x8090. The application space available will increase accordingly - 0x37f70.
This however assumes that interrupt vectors are not fixed in Flash but instead entered in SRAM (0x8080 can't be used for fixed vectors since they should be aligned - 0x8100 would be needed (and a different boot loader config).

Note that the uTasker KBOOT 2.0 compatible version also allows very strong IP protection using AES-256 as detailed here: https://community.nxp.com/thread/488740 

Regards

Mark

[burgeh]

Is this version you mention the bare-minimum bootloader? I read through and I see you have an example where the application is updated via http post by posting the data to a known place in memory. Does this come standard on the bare-minimum or what changes would need to be made?

[mjbcswitzerland]

Christopher

The "Bare-Minimum" loader performs the copy of the new application from any defined location (in internal Flash of external SPI Flash) to its final application location (optionally decrypting the content too). The "BM" loader is included in the uTasker package and is compatible with all Kinetis parts.

The "BM" loader itself doesn't include the communication code to accept and program the new application - this is the job of the application.

Regards

Mark

[burgeh]

Where do you define where it looks for the new application and where it

will copy to? I thought it would just point to the new application.

On Mon, Nov 26, 2018 at 3:04 PM mjbcswitzerland <admin@community.nxp.com>

[mjbcswitzerland]

#define uFILE_START        (unsigned char *)(FLASH_START_ADDRESS + 0x60000) // the address where the new application is located when present

#define FILE_SYSTEM_SIZE   (128 * 1024)                          // maximum size of new application

#define UTASKER_APP_START      0x1000                        // application location

[burgeh]

So if within my application I am able to write to an exact place in RAM on my chip via UART. If I press the reset to get back to the bootloader I would lose that .bin in the ram since it is not considered part of the application right?

Therefore how do I reset to the bootloader again with in the application so I don't need to reset the power?

[mjbcswitzerland]

Christopher

Although it is possible to save new code to SRAM and command the boot loader to restart without corrupting the image it is rather limited; the largest size of new application that could be loaded will be just a part of the SRAM size, whereas the SRAM size tends to only be a fraction of the size of the Flash, resulting in limiting new applications to a size of maybe 15%..20% of its Flash size.

Instead of locating the image to SRAM it is instead located to internal Flash (limiting the new application to about half the Flash size) or to external SPI Flash (no limitation) or to external NAND flash or SD card.

Regards

Mark

P.S. There is also a video showing details of its configuration and checking operation at:
https://www.youtube.com/watch?v=lm3M-ZlaFLQ

[burgeh]

Is there a function or what would be the best method to write a stream of data then to an exact address in internal flash?

[mjbcswitzerland]

Christopher

It depends on which libraries you are using for your application. In the uTasker environment there is a Flash file interface that can be used for writing streams of data to internal flash or external SPI flash.

The file system and low level interfaces are described in
http://www.utasker.com/docs/uTasker/uTaskerFileSystem_3.PDF

extern MAX_FILE_LENGTH uFileWrite(unsigned char *ptrFile,  unsigned char *ptrData,  MAX_FILE_LENGTH DataLength);
or
extern int fnWriteBytesFlash(unsigned char *ucDestination,  unsigned char *ucData,  MAX_FILE_LENGTH Length);

Regards

Mark

[mjbcswitzerland]

Christopher

If you have used the USB mode with Kboot you can also use its UART mode to do updates.

Otherwise there are various serial loaders available for the K22: http://www.utasker.com/docs/uTasker/uTaskerSerialLoader.pdf
or (if your application can accept and store the new code in either internal or external Flash) you can use this method http://www.utasker.com/docs/uTasker/uTasker_BM_Loader.pdf

If you prefer to redevelop your own rather than using a ready made one you can also copy bits or ideas from the open source uTasker K22 project on Github.

Regards

Mark

Kinetis: http://www.utasker.com/kinetis.html
Kinetis K22:
- http://www.utasker.com/kinetis/FRDM-K22F.html
- http://www.utasker.com/kinetis/TWR-K22F120M.html
- http://www.utasker.com/kinetis/BLAZE_K22.html
- http://www.utasker.com/kinetis/tinyK22.html

For less questions and faster, cheaper developments: try uTasker for Kinetis

[asfarley]

Hi Christopher

Yes, you can load from UART into program memory. I haven't done this on Kinetis but the process is basically the same on any MCU. Receive bytes over UART, write to program memory. 

I developed a fairly complex bootloader for AVR chips some time ago. In developing the bootloader, the key is to have a JTAG programmer where you can read back the device's flash memory. Then you can compare the contents of your .bin file byte-by-byte with internal flash memory, to confirm that program memory is ending up where you want it. 

Here's an application note to get started:

https://www.nxp.com/docs/en/application-note/AN2295.pdf 

Personally, I found that working from an existing bootloader code-base can be confusing becaues sometimes they're developed to support a wide variety of input channels for new program data, and a wide variety of architectures. I think it's reasonable to develop your bootloader from scratch just using a datasheet for your MCU; this way, you will end up with a very literal understanding of what's going on.

There's a lot of additional detail (you may want to use a CRC to validate program memory; you will probably need to become familiar with details of the memory-map in your MCU; etc etc), so feel free to post here again if you run into a specific issue.