How to store some default parameters in Flash?

[mehdikarimibiuk]

I want to store some default parameters in my Flash so that during boot-up time, my variables take those default values at start up.

How can I do this?

My controller is MK10DN512ZVLL10. And I am having a bare-metal project with the following build options:

Can you tell me what are these partitions like m_data and m_text for and how I can modify this, if I have to?

I want to specify a few parameters in Flash and let it stay forever. Then during start up, I would like to have a FLAG, if the flag is set, it means to take default parameters (will be our factory default parameters) for variables. If FLAG is clear it means start up the code normally.

[Kan_Li]

To do that, you have to modify the build option to generate a new lcf file, for example, a new 16bytes long section "m_param" is defined as below:

and in your code, use the following to predefine the data stored into that section:

#pragma define_section m_param ".m_param" abs32 RX

static __declspec(m_param) uint8_t m_param[0x10] = {

0x04U, 0x03U, 0x02U, 0x01U, 0x08U, 0x07U, 0x06U, 0x05U,

0x09U, 0x0AU, 0x0BU, 0x0CU, 0x0DU, 0x0FU, 0x10U, 0x00U

};

Please kindly refer to attachment for more details. !

Hope that helps,

B.R

Kan

[mjbcswitzerland]

Hi

Using a flash API in code doesn't require any linker script settings.

See the parameter system in the uTasker project as example: http://www.utasker.com/docs/uTasker/uTaskerFileSystem_3.PDF

Regards

Mark

[mehdikarimibiuk]

PE has a flash API called FLASH_LDD.

However, I need to set aside a read only segment of my FLASH to store my factory default values (1KB is enough). It should be read-only so no-one must be able to write to it, intentionally or unintentionally. I think using Build options in PE CPU is a way to go, but I have had some problems so far in configuring it.

[mjbcswitzerland]

Hi

Setting a sector in the linker script file will not stop "some-one" being able to write to it.

You can use region protection to do that, which is controlled by the flash configuration (a 16k block is possible with your chip).

For a small amount of data, such as serial number, MAC address etc. that is to be set once only there is a PROGRAM ONCE field (64 bytes in the K10) that can be used. This can be accessed using the API to set the values once, which can NEVER be modified again.

Regards

Mark

[Hui_Ma]

Hi Mehdi,

When you using Processor Expert FLASH_LDD component, it doesn't need to set a separated segment in the lcf file.

You can refer attached project, which calls FLASH_LDD provides Flash read/write driver function to do Flash operation.

It just need to define Flash start address.

Wish it helps.

Best regards,

Ma Hui

[mjbcswitzerland · Accepted solution]

1. Details about flash protection are in sector 28.4.2. of the K10 user's manual. The technique is the same for all K types. Search for "flash protection" in the user's manual to find several references to other details.

2. R/W etc. in the linker script just tells the linker whether it may locate code, consts and read/write variables.

If you specify a 'named' read-only sector and define that a group of consts will be located in it this (eg. as the reset vector is usually located) will work to set the values at specified Flash addresses, but if you just want a const table somewhere in code its location is not really important. If you are using API to set data in a sector the linker doesn't need to know about where this is - as long as it doesn't put code there (often using the final sector in Flash for storage is simplest since code is located from the start of flash, leaving space at the end of other usage). What it won't do is stop the application itself from deleting this area and writing different values (using API). It also won't stop any one reading out, erasing and programming different values via JTAG.

If 'physical' erase/write protection is not critical you could also simply write the API user interface so that it allows one set of values to be programmed. Once it detects that a (valid) set is already there (eg. not blank or with a valid check sum) the API user interface simply doesn't let this area be erased and reprogrammed (by further commands). This may be adequate in many cases - also your external EEPROM is not protected against modification of a malicious manner.

Regards

Mark