C90TFS driver for KL03 internal flash

[ee4hire]

New to kinetis & kds_v3. What are the steps to be able to use the C90TFS driver for my KL03 internal flash?

[xiangjun_rong]

Hi, William,

If you do not need to erase/program one page array to flash, you just want to write the Flash Configuration field from 0x400 to 0x40D, it is okay to change the file for example startup_MK82F25615.s(I use the SDK example) based on KDS3.x:

/* Flash Configuration */
    .section .FlashConfig, "a"
    .long 0xFFFFFFFF
    .long 0xFFFFFFFF
    .long 0xFFFFFFFF
    .long 0xFFFFBDFE

In the linker file

/* Specify the memory areas */
MEMORY
{
  m_interrupts          (RX)  : ORIGIN = 0x00000000, LENGTH = 0x000003C0
  m_bootloader_config   (RX)  : ORIGIN = 0x000003C0, LENGTH = 0x00000040
  m_flash_config        (RX)  : ORIGIN = 0x00000400, LENGTH = 0x00000010
  m_text                (RX)  : ORIGIN = 0x00000410, LENGTH = 0x0003FBF0
  m_data                (RW)  : ORIGIN = 0x1FFF0000, LENGTH = 0x00010000
  m_data_2              (RW)  : ORIGIN = 0x20000000, LENGTH = 0x00030000
}

  .flash_config :
  {
    . = ALIGN(4);
    KEEP(*(.FlashConfig))    /* Flash Configuration Field (FCF) */
    . = ALIGN(4);
  } > m_flash_config

It is a simple way to set the Flash Configuration field.

Hope it can help you

BR

Xiangjun Rong

[ee4hire]

Thank you for your posting, but that is what I first tried. Problem is kds_v3 will not allow FTFA_FSEC bit 0 be set. Whenever it sees the data to be written would turn on protection of the flash, it won't write that data. 

[ee4hire]

I'm simply trying to write the FTFA_FSEC bit 0 so I can protect the flash for my customer's application. No matter what I try in kds_v3 to set that bit, the tool "protects me not being able to debug" and always clears that bit from my .elf file, even if I just try to program from elf (instead of debug).
Can't figure out how to use the KDSK v1.3 C90TFS. I've read the KDSK 2.x has the flash driver as an fsl_... driver like the other peripherals. Tools / software supported spread sheet shows KDSK 2 available, but can't find a way to download it., All I can find are configurators.
Never had so much trouble just doing the simple task of protecting the flash from copying....

[mjbcswitzerland]

Hi

See also http://www.utasker.com/kinetis/FRDM-KL03Z.html
The uTasker project (available as open source at the link below) includes all flash operations needed to work without needing to worry about the drivers used. It also simulates Flash operations for study and test/debug purposes.
Try the binary at the bottom of the page which allows you to experiment with reading/writing and erasing and see this video for general details: https://www.youtube.com/watch?v=Pe9A8qsefzQ

The project includes all this operation integrated as developer's interface (storage system), parameter system and file system which adapts itself to whatever Kinetis chip is being used.

Regards

Mark

http://www.utasker.com/kinetis.html

[ee4hire]

Thanks, but I don't see how this will solve my problem. I'm just trying to erase and then write a couple of bytes from an ap developed in kds_v3 with KDSK 1.3. Don't understand that the uTasker gives me what I need, unless I'm missing something.

[mjbcswitzerland]

William

Sorry, but your question is not clear. Your issue probably has nothing to do with the Flash driver (whereby I was showing you how you could compare and simulate proven code to correct any library bugs, or to save development times and costs in case you were just starting out on a development by using a complete framework rather than having to integrate just simple flashing routines).

From your further posts (where the actual question first becomes more clear) it looks like either you have a problem to set the Flash configuration values or you have a problem with the programming tool (more likely the debugger than the IDE).

If the first is the case you need to define the Flash configuration program protection long word at address 0x408. In the uTasker reference it is a define which is easy to set:

#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'

In the KDSK it is somewhere in an assembler file somewhere.

If the second, you need to look around in the debugger configuration for settings which allows user flash configuration setting to be used. Some debuggers set fixed values to stop inexperienced uses writing things that could cause the debugger to be locked out and the processor effectively bricked for development work. I only know of the security settings being blocked by default and not flash protection so this is less likely the issue.

Regards

Mark

[ee4hire]

Mark, thanks.

Yes, I seem to be all over the map here just trying to solve my problem. Not starting a new development, we have working code for the product, but just as my customer was ready to start a large build, they asked for the security. I just seem to keep getting foiled however I try to implement this.
My goal is to find a way to secure the flash, i.e., set FTFA_FSEC in the flash security configuration field bit 0 to a 1. This, as you know, is loaded into the FSEC register at reboot. So I've been trying:

1. Setting the desired data in the startup file, just as Xiangjun Rong pointed out above. This is what has been thwarted by the debugger in kds. I have not been able to find configuration that changes the behavior of not allowing the protection to be set in the security configuration field (long word at 0x0408). I'll continue to look for that, but so far no luck.

2. My second approach to setting the protection to write code to directly write the field. I've pulled in just the routines I need from the KDSK 1.3 to erase a sector and then write the field. I simply do an init, an erase sector, and a program of the bytes in question. Trouble is, though the commands compile and complete with non-error return codes, the flash never changes. So now I'm wondering if the driver is just not operating properly or I'm missing some step necessary to write the flash.

I suspect that many have successfully protected the flash in this environment, just hoping to find someone who has done it successfully and can point me to something that works.

[mjbcswitzerland]

William

To set security you need to use the byte at 0x40c.

It is true than many debuggers won't allow you to change this and it depends on the debugger used (which one is it?). If the setting is not obvious in the debugger configuration (under the IDE being used) you may need to contact the debugger manufacturer to get the details.
There is usually also a programming utility available for the debugger which works without the IDE which may be more easy to control (with more options and faster operation).

Regards

Mark

[ee4hire]

I'm using GDB with a Segger J-Link for the debugging. Scouring the settings but haven't found anything yet.

I do think finding a separate programming unit might be the answer, but that complicates things because production in China is already using the kds_v3 to program using .elf files we supply. (This is why writing code to do this as in my thread with xiangjun.rong might be the better way.

[mjbcswitzerland]

William

I would contact Segger because they may be able to tell you how to do it without needing to invest programming time.

If you find no alternative it is possible to update the security setting in code whereby you need to copy the complete first Flash sector to a temporary RAM buffer, modify the security setting and write it back. Since this temporarily erases some code you need to ensure that the routines being used are never located in that sector (or else run the complete code involved from RAM). Also ensure that interrupts are disabled during the operations.

Here is code to do it:

extern int fnSecureDevice(void)
{
    unsigned char first_sector[FLASH_GRANULARITY];
    memcmp(first_sector, fnGetFlashAdd((unsigned char *)0x00000000), FLASH_GRANULARITY); // load the first sector from Flash
    if (*fnGetFlashAdd((unsigned char *)0x0000040c) != (FTFL_FSEC_SEC_SECURE | FTFL_FSEC_FSLACC_GRANTED | FTFL_FSEC_MEEN_ENABLED | FTFL_FSEC_KEYEN_ENABLED)) { // check whether the device is already secured
        first_sector[0x40c] = (FTFL_FSEC_SEC_SECURE | FTFL_FSEC_FSLACC_GRANTED | FTFL_FSEC_MEEN_ENABLED | FTFL_FSEC_KEYEN_ENABLED); // change the required protection value
        _fnEraseFlashSector((unsigned char *)0, _FLASH_GRANULARITY);  // delete first sector
        _fnWriteBytesFlash((unsigned char *)0, first_sector, FLASH_GRANULARITY); // program back
        return 1;                                                     // has been secured
    }
    else {
        return 0;                                                     // was already secured
    }
}

This operates in the uTasker project and its KL03 simulator (you can use the open source code and Visual Studio and simulate the operations) and you can replace parts with C90TFS calls if preferred. In case of difficulties with the C90TFS libraries you can either take parts from the uTasker libraries or use them as comparison to fix the issues.

Regards

Mark

[ee4hire]

Mark:

Thanks.

First, I've decided it is much better to get this into the code rather than relying on a debugger setting. The will assure that we set the protection; not necessarily true that the CM will always get a special configuration correct.

No luck with the C90TFS call, still just plain doesn't work. I'll give the driver from the uTasker project a try in my code. BTW, I'm flush with flash at the moment, so I've adjusted my map to not put any code in the 0x400-0x7ff sector. Easier than figuring out how to keep my code and any C library routines it calls from ending up in the next sector.

Thanks,

Bill

(Signed up some time ago and there isn't an easy way to change my name in my profile....)

[xiangjun_rong]

Hi, William,

How do you know that you do not write the Flash configuration field successfully? I suggest you read the byte in the 0x40D(FOPT) and 0x40C(FSEC) and output the two words to HyperTerminal via UART, what is the result?

Hope it can help you

BR

Xiangjun rong

[ee4hire]

Yes, I have a serial port as my main logging / debugging tool. Below I paste the serial port output:

FSEC=0xfe, FOPT=0x1a, flash protection (next reset):DISABLED, buf = 0xfe, 0x1a
FlashInit(): rc = 0x00

PFlashGetProtection(): rc = 0x00, protectStatus = 0xffffffff

FlashGetSecurityState(): rc = 0x00, securityState = 0x01

FlashEraseSector(): rc = 0x00
FSEC=0xfe, FOPT=0x1a, flash protection (next reset):DISABLED, buf = 0xfe, 0x1a

FlashProgramFlash(): rc = 0x00
FSEC=0xfe, FOPT=0x1a, flash protection (next reset):DISABLED, buf = 0xff, 0x1a

FSEC is a read from flash at 0x4c, FOPT is a read from flash at 0x4d. As you can see, right after the FlashEraseSector (for which I give an address of 0x400 and size of 1024, sector size in this flash), the data at 0x40c and 0x40d to not change, even though the function return code (rc) is 0 (FTFx_OK).