Programming the FTFA_FOPT register using blhost.

[dougbaker]

I have a KL17 I would like to be able to force the chip to the bootloader using the kl17’s reset pin and the BOOCFG0 pin.  According to the documentation on the KL17, I need to program the bits in the FTFA_FOPT register and write the value ZERO to bit NMI_DIS and also a ZERO to the BOOTPIN_OPT.  I would like to write the value 0xF9 to the register FTFA_FOPT.

The write to the register FTFA_FOPT is an indirect write where I need to write to the flash at location 0x0000_040D because the chip will read the contents of address 0x0000_040D and put it the FTFA_FOPT register.

Using blhost, I do the following:

blhost -p COM44,115200 flash-erase-all-unsecure

blhost -p COM44,115200 read-memory  0x040C 4

blhost -p COM44,115200 write-memory 0x040C {{FEF9}}

blhost -p COM44,115200 read-memory  0x040C 4

now I power cycle the CPU and read the memory:

blhost -p COM44,115200 read-memory  0x040D 1

Ping responded in 1 attempt(s)

Inject command 'read-memory'

Successful response to command 'read-memory'

f9

(1/1)100% Completed!

Successful generic response to command 'read-memory'

Response status = 0 (0x0) Success.

Response word 1 = 1 (0x1)

Read 1 of 1 bytes.

As you can see, the address 0x040D is reading F9 so it has the correct value.

I then program an application on the KL17 using blhost:

blhost -p COM44,115200 flash-image kl17_ShockSense.hex erase

blhost -p COM44,115200 reset

The app I put on the KL17 only jumps to the boot code and does not touch the flash at all to erase or write it.  After the code jumps to boot, I can use blhost to read the flash again and the value at address is now 0x3F and not 0xF9. 

blhost -p COM44,115200 read-memory  0x040D 1

That tells me something would have to erase the flash at the location to change the ‘9’ to a ‘f’ and also then write the location to change the ‘f’ in the 0xf9 to a ‘3’.

Any ideas?

Thanks,

Doug

[dougbaker]

The problem has been found.  There was a  "Flash Configuration" definition in a assembly file that was overwriting the flash when we programmed the application.  We found the problem by looking at the memory map at the address that was being written by the application file we were building and then found the definition in the assembly file.

[Jorge_Gonzalez]

Hi Doug,

Thank you for coming back and sharing your finding. Indeed, the startup assembly file usually has the flash configuration data.

Regards!

Jorge Gonzalez