[narke]

Hi,

My board has 32K SRAM in the code memory area (within the first 0.5G), also has the same size of build in SRAM in data area. My question is, what kind of data are suitable to put in CODE area? Particularly, should I set the main stack in CODE SRAM or DATA SRAM?

Thanks in advance.

[Alban Rampon]

Hello,
Linkers I've used all understand the CODE segments as being READ_ONLY.
Therefore I would not put a stack there... and the stack is not code.
Still, your question being on the vague side, it's not necessarily easy to grasp what you are working on.
Kindly,
Alban.

Edit: spelling

[Joseph Yiu]

I guess you are using a NXP Cortex-M3 microcontroller? (Please be more specific on device type)

If that is the case, to get the best performance (program execution as well as interrupt latency), the stack should be place in the SRAM in the SRAM region. This allows stack operations and program fetches to take place at the same time.

[narke]

Joseph, on 21 June 2011 - 04:47 PM, said:

I guess you are using a NXP Cortex-M3 microcontroller? (Please be more specific on device type)

If that is the case, to get the best performance (program execution as well as interrupt latency), the stack should be place in the SRAM in the SRAM region. This allows stack operations and program fetches to take place at the same time.

Yes, your guess is perfectly right! I am using NXP17cxx board. For the board, 50% SRAM are arranged in CODE region, another half are in SRAM region. I also have the same thinking about placing the stack on SRAM rather than CODE. But what kind of data (with r/w accessing) are suitable to be placed in CODE region? It's not affordable of not using the 50% of the total SRAM space.

Looking forward for you answer.

Best Regards,
narke

[Joseph Yiu]

The reason to have half of the RAM in CODE region is to have high speed program execution from SRAM.
By having two SRAM units, you can have data and instruction accesses at the same time (havard bus architecture).

To use this, you need to copy your program code (or at least some part of it) from flash to this SRAM in CODE region, usually during start up process. (Note: You need to link your program correctly to match the run time memory map).

Although NXP has a flash memory prefetch unt, which avoid wait state in sequential accesses, wait state of the flash memory still affect the performance in branches, or some other non-sequential accesses to flash. By using this SRAM for program execution, you can eliminate the effect of flash wait state.

From my understanding there is nothing to stop you from using this SRAM (in CODE region) for stack or data variables. But this SRAM region is not covered by bit-band feature. And depending on how NXP implement the bus interconnections, you might (Note: I don't know, you need to do your own benchmark) find that performance of the system reduced because stack/data operations and program accesses use the same bus (it became von Neumann bus architecture).

regards,
Joseph

[narke]

Joseph, on 22 June 2011 - 08:18 PM, said:

The reason to have half of the RAM in CODE region is to have high speed program execution from SRAM.
By having two SRAM units, you can have data and instruction accesses at the same time (havard bus architecture).

To use this, you need to copy your program code (or at least some part of it) from flash to this SRAM in CODE region, usually during start up process. (Note: You need to link your program correctly to match the run time memory map).

Although NXP has a flash memory prefetch unt, which avoid wait state in sequential accesses, wait state of the flash memory still affect the performance in branches, or some other non-sequential accesses to flash. By using this SRAM for program execution, you can eliminate the effect of flash wait state.

From my understanding there is nothing to stop you from using this SRAM (in CODE region) for stack or data variables. But this SRAM region is not covered by bit-band feature. And depending on how NXP implement the bus interconnections, you might (Note: I don't know, you need to do your own benchmark) find that performance of the system reduced because stack/data operations and program accesses use the same bus (it became von Neumann bus architecture).

regards,
Joseph

Joseph,

Thanks for the very clean explanation. For our application, because the 32k RAM is definitely not enough, so we have to use the another 32K RAM in code region to store data other than code. In this case, you must understand, we have to decide to put what kind of data into the CODE region RAM space and keep the performance lost in a minimum level. So, putting stack into the CODE region is a good choice or not?

Thanks again,
narke

[Joseph Yiu]

Putting the stack in the SRAM in CODE region should be fine.
I don't know if it will affect the performance and interrupt latency, you need to do your own benchmark to test it.
regards,
Joseph

[Zova]

narke, on 20 June 2011 - 03:40 AM, said:

Hi,

My board has 32K SRAM in the code memory area (within the first 0.5G), also has the same size of build in SRAM in data area. My question is, what kind of data are suitable to put in CODE area? Particularly, should I set the main stack in CODE SRAM or DATA SRAM?

Thanks in advance.

Hi narke, may I ask how you access the I/D SRAM or say I/DTCM ? Have you modified your linker program? Now, I'm facing the same problem as you. I want to put some code in code SRAM (my board is S3C6410, ARM1176JZF-S based), but I've no idea about how to place code in.

Thanks,
Zova

[Joseph Yiu]

Hi Zova,

A easier way to do this is to enable the TCM during startup code, and program the coprocessor register for TCM configuration, and then copy the required program code into the I-TCM before entering main. However, this might not be possible in some boards with fixed firmware / OS.

Have you look at the TRM?
http://infocenter.ar...h/Chdhbjjb.html

regards,
Joseph

[Zova]

Joseph Yiu, on 28 June 2011 - 09:00 AM, said:

Hi Zova,

A easier way to do this is to enable the TCM during startup code, and program the coprocessor register for TCM configuration, and then copy the required program code into the I-TCM before entering main. However, this might not be possible in some boards with fixed firmware / OS.

Have you look at the TRM?
http://infocenter.ar...h/Chdhbjjb.html

regards,
Joseph

Thanks Joseph, and sorry for my late reply. I've read the link above. And can you see this topic just posted.

Thanks,
Zova