Messages

1

NXP^TM M522XX, KINETIS and i.MX RT / Programming issues resolved with linker file change

« on: September 22, 2014, 10:57:45 PM »

After making a small change and rebuilding the serial bootloader for the Kinetis K60 I had problems programming it in to the target (using the Flash Programmer utility from within CodeWarrior, with a P&E Micro Multilink Universal FX). I had consistent errors programming the third segment, even after a full erase:

Code: [Select]

cmdwin::fl::write
 Beginning Operation ...   
-------------------------
Using restricted address range 0x00000000 to 0x000FFFFF   
Programming file C:\Users\mdkendall.ELEMENTS\Documents\SCU-Bootloader\Applications\uTaskerSerialBoot\KinetisCodeWarrior\uTaskerSer
ialBoot_FLASH\uTaskerSerialBoot.srec   
Auto-detection is successful.   
  File is of type Motorola S-Record Format.   
 
 Downloading Flash Device Driver ...   
 Reading flash ID ...
Auto-detection is successful.   
  File is of type Motorola S-Record Format.   
 
Downloading 0x00000008 bytes to be programmed at 0x00000000   
Executing program ....   
 Program Command Succeeded   
Downloading 0x00004D4B bytes to be programmed at 0x00000400   
Executing program ....   
 Program Command Succeeded   
Downloading 0x00000023 bytes to be programmed at 0x0000514C   
Executing program ....   
Error:  Program failed.   Flash driver reports the following error(s):  Chip reported error during program. Please check that the sector you are programming is erased.

After a bit of Googling I found a post on the Freescale forums that indicates an alignment of 8 is required.
https://community.freescale.com/thread/312328

The segment that failed to program was on a 4-byte boundary. I edited the linker file (\Applications\uTaskerV1.4\KinetisCodeWarrior\Linker_Files\K_1M_128.ld) to change all the ALIGN(foo, 4) directives to ALIGN(foo, 8 ) and that has fixed my problem:

Code: [Select]

cmdwin::fl::write
 Beginning Operation ...   
-------------------------
Using restricted address range 0x00000000 to 0x000FFFFF   
Programming file C:\Users\mdkendall.ELEMENTS\Documents\SCU-Bootloader\Applications\uTaskerSerialBoot\KinetisCodeWarrior\uTaskerSer
ialBoot_FLASH\uTaskerSerialBoot.srec   
Auto-detection is successful.   
  File is of type Motorola S-Record Format.   
 
 Downloading Flash Device Driver ...   
 Reading flash ID ...
Auto-detection is successful.   
  File is of type Motorola S-Record Format.   
 
Downloading 0x00000008 bytes to be programmed at 0x00000000   
Executing program ....   
 Program Command Succeeded   
Downloading 0x0000474C bytes to be programmed at 0x00000400   
Executing program ....   
 Program Command Succeeded   
Downloading 0x000005FF bytes to be programmed at 0x00004B50   
Executing program ....   
 Program Command Succeeded   
Downloading 0x00000023 bytes to be programmed at 0x00005150   
Executing program ....   
 Program Command Succeeded   

I haven't investigated this in any detail, but it has solved my problem.

2

NXP^TM M522XX, KINETIS and i.MX RT / Re: Bootloader application encryption

« on: May 14, 2014, 08:33:01 PM »

Thanks for your feedback, Mark, and sorry for the delay in replying.

Yes, this is for a real application. I have the bootloader working right now and it's fine for development, but I expect that for production we would want firmware updates that are distributed on SD cards to be encrypted in some way.

I don't have enough space in the MCU Flash for a second copy of the firmware, and decrypting to any other attached memory (or even the SD card itself) would result in a plain-text copy existing in an unsecured location. So decrypting would have to be done on-the-fly during the update process, on a block-by-block basis.

As an aside, I made some changes to the SD card bootloader to support wildcard matching in the name of the firmware file - instead of requiring the update to be named "firmware.bin" (or some other fixed name) it can be named e.g. foo-r124.bin by setting NEW_SOFTWARE_FILE to "foo-*.bin". When doing that I was surprised not to find a function in the API for the filesystem that would list the contents of a directory, returning a set of file handles or similar. I ended up with a nasty hack using the DOS-format text output returned by the utListDir() function. I'm not sure if that was the best approach but anyway, it seems to work. Patch file attached.

3

NXP^TM M522XX, KINETIS and i.MX RT / Bootloader application encryption

« on: May 02, 2014, 05:55:52 PM »

I'm still evaluating the "uTaskerSerialBoot" bootloader for use on Kinetis K60, particularly using SD cards as the main updating mechanism. I have the software building and running, and I am able to use it to bootload my application and update it from SD cards.

The one piece that I have not got working is encryption of the application. I see in ReleaseNotes-convert.txt that the conversion tool can be used to encrypt the application by giving it additional parameters. Presumably the encryption key chosen also has to be incorporated into the bootloader firmware, but I do not see where to enter it. I was looking in Loader.h and expecting it to be near the definitions of VALID_VERSION_MAGIC_NUMBER and _SECRET_KEY, but I don't see it.

The ReleaseNotes-convert.txt mentions uTaskerBoot_003.PDF, but I don't see any specific instructions in that document for how the incorporate the encryption key in the bootloader firmware.

4

NXP^TM M522XX, KINETIS and i.MX RT / Bootloader logic

« on: May 01, 2014, 05:43:05 PM »

Using the uTaskerKinetis_V1.4.4 distribution; building the uTaskerSerialBoot_FLASH bootloader target; comparing operation with the state diagrams on page 9 of "uTasker – Serial Loader User’s Guide" v1.02.

In the document there is a transition from the START state to STATE_ACTIVE after the UART is initialised. But I don't see that anywhere in the code. The task never got out of the START state.

I added the following after line 179 of Applications\uTaskerSerialBoot\Loader.c which has fixed it:

Code: [Select]

         iAppState = STATE_ACTIVE;
I don't know why that was necessary, but it appears to be working properly now.