Purpose of KEEP(*(CodeQuickAccess)) Extra Linker Script Input Section

[D_TTSA]

Good day

I would like to know what purpose this has in the Project properties -> C/C++ Build -> Settings -> Managed Linker Script window:

I came across it in an SDK example (can't remember which one), but I'm not sure of its purpose.

I know how to move functions into the SRAM_ITC_cm7 section (for increasing the speed of their execution) using:

__attribute__((section(".ramfunc.$SRAM_ITC_cm7")))

Does the KEEP(*(CodeQuickAccess)) section have something to do with this? Or is this unrelated?

[kerryzhou]

Hi @D_TTSA ,

   You mentioned CodeQuickAccess, can be found in the SDK code:

SDK_2_10_1_EVK-MIMXRT1060\boards\evkmimxrt1060\demo_apps\power_mode_switch

AT_QUICKACCESS_SECTION_CODE(void SwitchSystemClocks(lpm_power_mode_t power_mode));

#define AT_QUICKACCESS_SECTION_CODE(func) __attribute__((section("CodeQuickAccess"), __noinline__)) func
#define AT_QUICKACCESS_SECTION_DATA(func) __attribute__((section("DataQuickAccess"))) func

Then, you can find, it will put the SwitchSystemClocks API in the RAM, as this code need to run in the internal RAM, otherwise, it will cause the low power issues.

Wish it helps you!

Best Regards,

Kerry

[D_TTSA]

Hi @kerryzhou 

Thanks for your reply.

I'm quite certain that I saw this linker script section in another SDK example, because I hadn't seen the power_mode_switch example until you mentioned it.

But anyway, what I'm understanding from your message is that the KEEP(*(CodeQuickAccess)) section:

• Has nothing to do with improving performance
• Is purely for keeping code in the internal RAM (so, copying the code from FLASH into RAM) so that when you go into low-power mode and you can't access the FLASH, you can still run the code in RAM.

Are you absolutely sure that this isn't linked to how SRAM_ITC improves performance of the code that is placed in that section? If not, the "CodeQuickAccess" name is rather misleading.

[kerryzhou]

Hi @D_TTSA 

  No, you misunderstand me!

  The low power project is just the example to me to talk this case, of course, there still have other projects like that.

  Answer your questions:

1 Has nothing to do with improving performance

--Answer: why you understand the TCM code running performance not higher than the external flash?

internal TCM code running speed more quick that the external flash, so that is the performance changing.

Performance is not the only item, the codeQuickAccess also can avoid some conflict for the cache and the flexSPI, etc. As it run in the internal TCM which don't need cache.

2 Is purely for keeping code in the internal RAM (so, copying the code from FLASH into RAM) so that when you go into low-power mode and you can't access the FLASH, you can still run the code in RAM.

--Answer: No, some code have conflict with the flexSPI, eg, when do the low power clock switch, if it run in the external flexSPI, it will caused the issues, so the that code need to put in the internal TCM and run it in internal RAM. Just some code is special.

3. Are you absolutely sure that this isn't linked to how SRAM_ITC improves performance of the code that is placed in that section? If not, the "CodeQuickAccess" name is rather misleading.

--Answer: Code run in internal TCM is the quick code, the TCM clock speed is higher than the external flash, as you know, external flash also need to do the communication with the flexSPI interface, and the clock speed is slower than the TCM.

Wish it helps you!

Best Regards,

Kerry

[D_TTSA]

Hi @kerryzhou 

1. I understand that placing code in ITCM means it will run faster than when it is running from external flash. I have said this before. What I am asking is, how does putting "KEEP(*(CodeQuickAccess))" in the extra linker script input section settings affect performance? How is it linked to putting code in the ITCM? Because I know how to put code in the ITCM, using the __attribute__ qualifier

2. Okay

3. Again, I know that ITCM is faster. But you say here that "internal TCM is the quick code". ITCM stands for Instruction Tightly-Coupled Memory. This memory is optimised for holding instruction data, improving the speed of executing code. I understand that there are a few reasons for this speed improvement (clock speed, cutting out communication to flash, etc). What I don't understand is what the CodeQuickAccess linker script section has to do with ITCM. If it is necessary to put this linker script section in order to place code in the ITCM, then this should be stated. But I don't believe this is the case, since it seems to work in my project without doing this...

Kind regards

[kerryzhou]

Hi @D_TTSA 

1. how does putting "KEEP(*(CodeQuickAccess))" in the extra linker script input section settings affect performance? How is it linked to putting code in the ITCM? Because I know how to put code in the ITCM, using the __attribute__ qualifier

Answer: linker script contains :KEEP(*(CodeQuickAccess))

  It means, it will put the space of CodeQuickAccess in the internal ITCM, you can consider, ITCM will reserve one space for your CodeQuickAccess, it is the memory divide, not the mcuxpresso, other IDE, eg, IAR, MDK also do it the same way.

  Your __attribute__ qualifier just define the detail API to the CodeQuickAccess area.

  So, this can realize your detail API put in the internal ITCM demand.

2. What I don't understand is what the CodeQuickAccess linker script section has to do with ITCM. If it is necessary to put this linker script section in order to place code in the ITCM, then this should be stated. But I don't believe this is the case, since it seems to work in my project without doing this...

Answer: CodeQuickAccess linker file will define your CodeQuickAccess space in the internal ITCM, you can check your .map file, it will be more clear. This is the memory arrangement, linker file is used to the memory arrangement. If you don't do it, you can check your map file, whether you already put in the ITCM or not, and please also check your link file, whether you really didin't use it and API is located to the internal ITCM.

Just make sure your code is running in the external QSPI flash.

Best Regards,

Kerry

[D_TTSA · Accepted solution]

Thanks for your reply @kerryzhou 

I'm going to explain it back to you to see if I understand you correctly.

To run code from ITCM, with the aim of improving the speed of execution:

1. Use the __attribute__ qualifier when declaring functions to put them in the SRAM_ITC region. This puts the code in the correct region in internal memory.

2. Add the KEEP(*(CodeQuickAccess)) extra linker script section to inform the linker that the data in the SRAM_ITC region is code that is placed there for the fast-execution benefits.

Note: I compared the .map file when I have this linker script section (below, right) to when I don't (below, left). The only difference I found was this line that was added:

Perhaps you can explain what this difference means?

Kind regards

[kerryzhou]

Hi @D_TTSA ,

  In fact, you need to check the ld KEEP meaning at first:

You can also search it from website:

https://stackoverflow.com/questions/9827157/what-does-keep-mean-in-a-linker-script

Wish it helps you!

Best Regards,

Kerry

[D_TTSA]

Hi @kerryzhou 

Once again, I do not feel like you are addressing exactly what I've asked.

My questions:

1. I see the meaning of KEEP that you posted. Are you trying to correct my explanation in step 2? 
2.  Are my steps 1 and 2 correct for executing functions from SRAM_ITC?
3. Could you please explain what the new line added to the .map file does (shown above)?

Kind regards

[kerryzhou]

Hi @D_TTSA 

2.  Are my steps 1 and 2 correct for executing functions from SRAM_ITC?

Answer: I think it is correct. both 1 and 2.

3. Could you please explain what the new line added to the .map file does (shown above)?

Answer: You can see, your right side, map contains codeQuickAccess, it means, it insert the memory range to the ITCM, and that memory is named as codeQuickAccess.

In fact, both method can indicate the code to the ITCM, just define codeQuickAccess range it is more easy to control by the SDK, it is the SDK code style.

Wish it helps you!

Best Regards.

[D_TTSA]

Hi @kerryzhou 

First of all, you didn't answer question 1.

Second of all, in your answer to question 3, you say "both methods" can "indicate" the code to the ITCM. Do you mean that both step 1 AND step 2 place the code in the ITC - so there is no reason to do both? 

If this is the case, why does adding the linker script section change the .map file? Adding the linker script section clearly makes a difference here.

[kerryzhou]

Hi @D_TTSA 

  I think this question you need to post question in the IDE side:

https://community.nxp.com/t5/MCUXpresso-IDE/bd-p/mcuxpresso-ide

  As it is determined by the IDE ld file.

  You also can refer to this post:

https://community.nxp.com/docs/DOC-335283

 Which is about how to define the API to the specific area in mcuxpresso.

About question1, it indicate about the step2, so I answer you directly.

 I mean, it is the different way to put your API to the internal ITCM, your step1 and step2 is two way to put the code to the ITCM.

 more details about the linker file, and the generate map file, please check with our IDE engineer, as I am the RT chip technical engineer.

Wish it helps you!

Best Regards,

Kerry

[D_TTSA]

Hi @kerryzhou 

Could you please tag the IDE engineer in this post, as there is a lot of information that would need to be repeated if I were to create another post.

Kind regards

[kerryzhou]

Hi @D_TTSA 

  If you want to know more details about the IDE linker file and the map file, you can create the post in the IDE area.

  But, from my opinion, if you need some code run in the ITCM, I think you can do it like the SDK, divide the CodeQuickAccess area, and define API to it, this is the normal usage.

Wish it helps you!

Best Regards,

Kerry