RAM and Flash start adresses

[Chriis]

Hello,

I was reading this post on the forum: "Adjustment of RAM and Flash memory - Getting Started - nRF5 SDK guides - Nordic DevZone (nordicsemi.com)"

At point 4. "Change start addresses in Segger Embedded Studio" I wondered if you change the start adress of RAM to an adress that is further then the original adress. What happens to the RAM that is not defined?

Does the linker not put code there anymore? If that is true, is there any way you can put your own specific code there?

I want to achieve a data block where I can put specific arrays in and where the linker does not put anything else in.

[Hieu]

Hi Chriis,

If you are referring to the RAM_START configuration, then the RAM the application "moved away" from is going to be reserved for the SoftDevice.

Regarding reserving a RAM section for variable, I am going to refer you to some answers by my colleagues on DevZone:

- How to place data at a location by Einar:  RE: RAM Section allocated by Linker . 
- Details about RAM usage and variable placement in RAM by Håkon: RE: Some questions about RAM non_init .
- Another thread where a bootloader is also used: how to reserve memory segment using SES . 

If you have any further questions please let me know.

Hieu

[Chriis]

Thanks for answering!

I am quite new to this so I may find understanding a little harder than usual so please bear that in mind.

My goal is to make a sensor, the sensor needs to make a couple readings per hour. So when it is not active it will go into sleep mode. 

The sensor has data that needs to be stored to work properly. So this data has to be retained when the chip is off.

Now from what I understand is that normally the Linker puts all data in code on a "random" place in memory and I don't have control over where it is placed, so I need to seperate a section of RAM where the Linker does not put anything but when I need data to be retained I can place it there.

I am using the SES workspace.

This is my plan:

- Open linker file

- Split the RAM partition into 2 partitions.

- 1 partition the Linker can touch, and the new partition where I can put specific data in that needs to be retained.

- Place specific data in the partition that has been added (another question/problem that i need to solve).

Questions:

Where do I find the Linker file where I can edit the partitions?

When I edit the existing partition and make a new one, do I need to keep something in mind?

I hope that you can help me.

[Hieu]

In the nRF5 SDK, the bootloader is a separated application in charge of booting and DFU. The nRF5 SDK's bootloader solutions are documented here: https://infocenter.nordicsemi.com/topic/sdk_nrf5_v17.1.0/lib_bootloader_modules.html.

My colleague does not have any additional input regarding the adding of partition itself, but he notices a few things I missed in the information you have given me.

If you are planning to store the sensor data once and wake up every few hours, here are a few things to note:

• You can also store the sensor data to flash memory using the Flash Data Storage (FDS) library.
• Since you are worried about the application writing data over your sensor data, I think you might be planning to put the device into System OFF mode. Please note that in System OFF, you cannot run the RTC or TIMER peripherals to wake the device up regularly.

Also, could you please elaborate better on your concern regarding the linker putting data randomly over your region?

As far as static memory allocation goes, the linker decides where a variable stays during compile time. That means that after you build your project and the linker put your sensor data on address 0xabcd_ff00, then it will always be on that address. Once you program the device, your data will always be on RAM address 0xabcd_ff00 whether you run it through power cycles or putting it to sleep.

Could you be thinking about non-initialized RAM section instead of just simply a dedicated RAM section?

Finally, since you seem to be just starting your project, please know that the nRF5 SDK is now in maintenance mode, and we recommend new projects to use the nRF Connect SDK instead.

Of course, if you have a strong reason to use the nRF5 SDK, such as familiarity vs. project timeline, we would still be happy to support you with that.

[Chriis]

My concern is that I do not want the linker to put the, wanted to be retained data, in section 14 of RAM while section 1 is the only one is being retained. 

The sensor came with a library, and that library and its data needs to be retained in anyway possible. I thought this was the best way but now I am questioning it.

a not initialized RAM section would be perfect too, it will be basically the same thing in the project. The problem is how is this done?

-

Is it not just easier to offload the desired data to Flash and then disable all RAM sections?

Also I am taking over the project from someone else so there has been done quite a few things already. I don't think it is a good idea to switch to nRF connect.

[Hieu]

Chriis said:

a not initialized RAM section would be perfect too, it will be basically the same thing in the project. The problem is how is this done?

This is discussed in one of the links from my first reply.  RE: Some questions about RAM non_init .

Chriis said:

Is it not just easier to offload the desired data to Flash and then disable all RAM sections?

As I mentioned, storing the sensor data to flash is a perfectly fine option. Please just take care to let the flash write completes before putting the device to sleep; it is far less instantaneous than a RAM write.

Disabling RAM sections is only for lowering power consumption, since your device's sleep time (two hours) is so much more than its wake time (likely seconds just to read the sensor and save it). What are you planning to do with disabling RAM sections?

Chriis said:

Also I am taking over the project from someone else so there has been done quite a few things already. I don't think it is a good idea to switch to nRF connect.

I see. If the project is in maintenance, then that is a fine reason not to change SDK.

Please be informed that it is the Easter holiday here, and responses on DevZone can be delayed. I will also be out of office from tomorrow and will return to support you from Tuesday next week. My apology for the inconvenience.

Hieu

[Chriis]

Ok, I had a hard time understanding that link, I will try and look at it again this week with some other colleagues. 

Thanks, I will keep in mind that Flash writing is not as fast. Also, my goal with disabling RAM is like you said. The device will be in sleep more often than not, so to reduce power consumption. 

The thing with Flash is that the program will be more error sensitive. So I don't really want to do that to be honest.

Happy Holidays, I will try and look at it myself and I will let you know when I am still stuck.

[Chriis]

Hey Hieu

First of all, hope you had a good easter!

Now to the code, I think I almost figured it out.

I am working with a renesas sensor which has a library that needs to be stored. 
I want to put this library directly in the linker script so I can know where it is placed and which RAM sections need to be powered.
However, Nordic uses a custom Linker script that is translated to a normal script when compiled.

The problem here is, I have no idea how to use or edit this script. So can you tell me and show me how I edit the existing linker script (flash_placement.xml) so I can put the object file directly in the linker?

So I want to connect this file to the linker. It is 6048 Bytes.

[Hieu]

Hi Chriis,

I had a good time. Thank you 

If you want to integrate a library into your project, shouldn't it be on Flash memory and not on RAM? Or perhaps there are some special functionalities that you need on RAM?

[Chriis]

Hey Hieu,

There are some algoritms and AI functionality in the library so I am quite sure it needs to be in RAM.

To be sure I have asked Renesas, but for now I will assume that it needs to be in RAM.

[Hieu]

Hi Chriis,

Execute code from RAM can be done. There can be some benefits to performance due to the access speed, but the benefits will be minimal, because the nRF SoCs' caches are pretty good, while the CPU is not fast enough to leverage the advantage of code being on RAM.

Could you please share a link to your conversation with Renasas if it is public? I would like to wait for their answer before we commit to what you are asking for. I just feel that it is not worth it because it's just too much work for too little benefit.

[Chriis]

community.renesas.com/.../105088