topic Change protection K64 in Kinetis Microcontrollers

Change protection K64

pietrodicastri — Fri, 25 Sep 2015 09:31:30 GMT

Good morning

I am paying with the protection changing, using the kinetis bootloader 1.2

I use the g_bootloaderContext.memoryMap[ kIndexFlashArray ].memoryInterface->read( ... )

for reading the flash from address 0 to 4095 in a buffer. I change the protection at the offset of the configuration word,

setting one bit of the FPROT. Then I rewrite the buffer in flash.

The operation appears successful, If I enquiry the protection situation the section is flagged as protected (after a reset).

The problem is, if I try to repeat a similar operation, the reading of the flash is no more possible, the CPU resets.

What is happening???

Tha

Re: Change protection K64

Jorge_Gonzalez — Sat, 26 Sep 2015 01:52:04 GMT

Hello Pietro di Castri:

Sorry, I got confused.

I change the protection at the offset of the configuration word, setting one bit of the FPROT. Then I rewrite the buffer in flash.

Could you please clarify this?

Are you doing this with the project code or with the blhost tool?

Please let us know more details or code snippets to understand your situation better.

Regards!

Jorge Gonzalez

Re: Change protection K64

pietrodicastri — Sun, 27 Sep 2015 09:46:36 GMT

Good morning.

and thank You for the assistance.

I try to dump the action I take..

	uint32_t start, length;
	start = g_bootloaderContext.propertyInterface->store->flashStartAddress;
	length = g_bootloaderContext.propertyInterface->store->flashSectorSize;
	g_bootloaderContext.memoryMap[ kIndexFlashArray ].memoryInterface->read( start, length, fbuf );

The previous code reads the first 4096 bytes of the flash.

At the addresses 0x0_0408 - 0x0_040B are the Program flash protection bytes. I reset one bit in the address

0x0_0408, in the fbuf, corresponding the FPROT0,

I rewrite the buffer

g_bootloaderContext.memoryMap[ kIndexFlashArray ].memoryInterface->write( start, length, fbuf );

I expect to protect the first 32 Kb of the flash.

I reset the processor.

When I ask the protection situation with

flash_is_protected( ... );

I get one section protected. Everything is ok.

But if I try to read from the same address the processor resets. Simply the reading...

Let me know ....

Best Regards

Pietro

Re: Change protection K64

pietrodicastri — Sun, 27 Sep 2015 11:45:23 GMT

Good morning again

I have found a problem. I don t delete the sector before the rewrite. Now the protection modification appears to work.

But I see a problem from a different perspective. If I change the protection for the section 0, containing the FPROTx ,

There will be no way to modify the protection, because the flash in itself is protected. Is a back door action is still possible?

Or maybe the backdoor is related to the security rather than the protection...

Is it ????

Thank You

Pietro

Re: Change protection K64

pietrodicastri — Sun, 27 Sep 2015 17:25:44 GMT

Hello Jorge

I am working like a horse to finalize the bootloading..

I see now another problem:

The HEX file produce a string

:04D41C0011040000F7

The address D4C0 fails the flash_check_range( ... )

But I need to write there...

So what do to????

Thank You

Re: Change protection K64

pietrodicastri — Tue, 29 Sep 2015 07:28:46 GMT

Hello Jorge

I understand it is not so interesting and I am creating some confusion.

I am using a console for the boot load, so I am bypassing the offered protocol now.

I am accomodating the relevant problems now.

The write function defaults to the status_t flash_mem_write(uint32_t address, uint32_t length, const uint8_t * buffer )

using the programming without the flexram.

In the driver also a possibility exists, it seems. I see the

status_t flash_program_section(flash_driver_t * driver, uint32_t start, uint32_t * src, uint32_t lengthInBytes)

in the flash_program_section.c. Do You think it is possible to use??

Is there a documentation of the performances of the two approaches? I am writing in small chunks of 16 or less byte per time,

I don t know if it is worth to use the FLEX ram

Thank You

Pietro

Re: Change protection K64

Jorge_Gonzalez — Tue, 29 Sep 2015 20:09:00 GMT

Hello Pietro>

Sorry for the delay.

You can use either of the available programming functions, as long as the flash spaces to write are previously erased.

If you have enough data to fill the program section buffer (FlexRAM space) then using the program section command is of course advisable, since you eliminate some delays between programming 8-bytes at a time with the Program Phrase command. Other than that then the command used will entirely depend on your application or the bootloader.

About the backdoor key, that is only for use when the MCU is secured. For detailed information there is an application note:

http://www.freescale.com/files/microcontrollers/doc/app_note/AN4507.pdf

Regards!

Jorge Gonzalez

Re: Change protection K64

pietrodicastri — Thu, 01 Oct 2015 09:31:28 GMT

Good morning

Thank You for follow up. I have a good solution for the flash writing and interaction with protection and security.

I write correctly all the application code in the flash.

But I am definitely in a hell, when jumping to the target application.

The jump_to_application(...)

function has the farewellBootloader() .. The MSP and PSP are correctly loaded, the program counter is loaded with the correct address.

I see the first instruction of the target application, but there is no way to proceed, the hard fault handler is resetting the CPU.

It could be related to some privilege or register situation on the ARM core. I really do not understand.

If at reset I force the program counter to the target application ( same as farewellBootloader ) The target application execute normally..

What can this hell be....????

Thank You

Re: Change protection K64

pietrodicastri — Thu, 01 Oct 2015 15:37:55 GMT

Hello Jorge

I had a very hard day... The invstat in the hard fault register status tells me the jump instruction need to provide

always an odd address. When jumping to the main application the address of the main is provided with

farewellBootloader = (void (*)(void))( applicationAddress );

and the C code

farewellBootloader();

will produce the hard fault.

I modify with

farewellBootloader = (void (*)(void))( applicationAddress | 1 );

and Everything works fine. I wander how this error is there..

Your comments are welcome..

Thank You

Pietro

Re: Change protection K64

Jorge_Gonzalez — Thu, 01 Oct 2015 22:58:36 GMT

Hello Pietro:

In the original KBOOT bootloader the applicationAddress is taken from the application's vector table. When filled correctly with the linker/compiler of the application's project, then the vector table should have the entry point address already considering the +1.

From your issue I guess you are hard-coding the applicationAddress instead of taking the value from the vector table.

I hope this clarifies.

Regards!

Jorge Gonzalez