nRF Connect SDK -place variable in flash at predefined location

[Hauser]

Hey all together,

I'm using nrf Connect SDK 2.0.0 and want to place a variable in flash at a predefined location. The reason is, that I need to read the information stored in this variable from the resulting hex file.

How can I do this? 

The "settings software module" places it somewhere in the reserved flash segment for user content. Thus I can not use that.

Thx in advance!

BR Hauser

[Jared]

Hi there,

I don't think any of the flash APIs offers this feature. Usually they partition the memory and writes only within a specific partition etc. I think you might have to use the NVMC peripheral directly and write to flash. We don't have any example for this, but you can find the documentation for the peripheral here. This isn't trivial though, which is why I would recommend using the APIs.. 

regards

Jared 

[Hauser]

Hey Jared,

I'm not sure whether I understood you correctly, but I want to place that variable at compile time in the flash. I don't think the NVMC peripheral can help here, as it only allows to place the data in flash during run time.

In Segger Embedded studio I did that with some precompiler instructions (like #pragma...) and extra flash pages, that I reserved in the linker file. I think I can do this here too, but I have no idea what are the precompiler instructions that are used for that.

Any suggestions?

Thank you,

BR Hauser

[Jared]

Hi,

Yes, I totally misunderstood you. 

But could you elaborate a bit more on your use case, what problem you are actually trying to solve, and what you are going to use it for? It would be much easier for me to suggest the appropriate method if I knew your use case.

Could you also give me an example on how you implemented it with SES and #pragma 

regards

Jared 

[Hauser]

Hey Jared,

there are several examples:

One is that the configuration of the firmware is stored in a struct (it's like a simple byte array). This configuration is placed on a specific address in flash and during the device production several device variants can be produced just by modifying this memory segment in the hex file and then flashing it to the device.

To do so, we have a data type Settings_t and place it with the following lines in the memory section .settings_section :

static Settings_t __attribute__((section (".settings_section"))) Settings = SETTINGS;

In the linker file, we defined this section before by this line:

<ProgramSection alignment="4" load="Yes" name=".settings_section" start="0x30000" size="0x1000" />

The #pragma commands are used in older compiler version, that are not suitable for Nordic chipsets.

I hope this makes better understand, what I need to solve.

Thank you,

BR Hauser

[Jared]

Hi,

Will this configuration be modified by software updates? More specifically, will it only be modified after the hex has been flashed during production?

In that case, couldn't the OTP registers in the UICR be used? 

I discussed this with some of our developers, and they suggested the following:

If this does not have to be part of application image (hex), but rather something that is stored on a device and may be accessed by different application (but not modified). It should be possible to just reserve single page of SOC flash for that purpose, using partition manager or DTS fixed-partitions entry, and obtain offset of this region using FLASH_AREA_OFFSET macro. This offset, in case of SOC, is beginning of SOC flash and can be casted to any type.

Additional advantage of using such approach is that this page will not be included into hex generated by build process and can be generated outside of the build process and merged with application hex, if desired.

Unfortuanly, I couldn't find a sample that does something similar.

regards

Jared

[Hauser]

Hey Jared,

got it what you are writing. We are using UICR->Customer register for similar topics on nRF52 series.

Good to know, how the flash area can be reduced to add "external" hex content. Thank you for that information. That's really helpful to solve the problems where the flash content won't be updated after production.

In other tasks, we gonna store firmware characterisation information (name, version,...) in such flash segments. These obviously must be updated during later firmware update process. Thus it must be part of the application image.

My impression is, that Zephyr does not provide such a function (to store data at specific memory addresses within the firmware image) as it would come into conflict with the integrated firmware update process.

Do your engineers agree on that?

Thank you and best regards,

Hauser