Migrating Kinetis-L Projects from Beta to Final MCU 10.3

I have successfully used CodeWarrior for MCU10.3 beta version for many projects. With the advent of the final CodeWarrior for MCU10.3, I want to migrate my existing projects to the new and final version. First: my existing projects work as well in the final version, which is good news. But there are two things to change to take advantage of the final 10.3:

  1. Linker file memory split
  2. ARM Micro Trace Buffer (MTB) support

Linker File Memory Split at 0x2000’0000

In the beta version, linker files for Kinetis L family had a memory split at address 0x2000’0000:

MEMORY {
  m_interrupts (RX) : ORIGIN = 0x00000000, LENGTH = 0x000000C0
  m_text      (RX) : ORIGIN = 0x00000410, LENGTH = 0x0001FBF0
  m_data_1FFFF000 (RW) : ORIGIN = 0x1FFFF000, LENGTH = 0x00001000
  m_data      (RW) : ORIGIN = 0x20000000, LENGTH = 0x00003000
  m_cfmprotrom  (RX) : ORIGIN = 0x00000400, LENGTH = 0x00000010
}

In the above linker file, the whole SRAM is splitted into m_data and m_data_1FFFF000. Such a memory split is required for the Kinetis K family (e.g. K60), as different memory controllers are used for each area. As such, linker objects shall not cross that boundary at 0x2000’0000.

However, the L family implements things differently, and such a split is not necessary any more. Keeping that split is not a big issue at first hand. But if I want to use the whole SRAM memory, having such an unneeded split is complicating things. New projects created with MCU10.3 do not have that split any more. So I want to apply this to my existing projects too.

💡 Such an ‘unsplitted’ memory map is as well needed for the MTB (Micro Trace Buffer) feature presented later in this post.

To migrate existing Processor Expert projects to the simplified memory map, I select the CPU component. In the Build Options tab I choose ‘Click to set default’ to apply the new memory map:

Click  to set default

Click to set default

Actually, it means clicking into the field and then click on the ‘…’ button:

💡 Clicking into the property field first to show the ‘…’ button is a problem of the UI.

Click button to set default

Click button to set default

This triggers a confirmation dialog:

Do you really want to set all areas to the default

Do you really want to set all areas to the default

After confirming that, my memory areas get reduced, and after code generation my linker file gets simplified too:

MEMORY {
  m_interrupts (RX) : ORIGIN = 0x00000000, LENGTH = 0x000000C0
  m_text      (RX) : ORIGIN = 0x00000410, LENGTH = 0x0001FBF0
  m_data      (RW) : ORIGIN = 0x1FFFF000, LENGTH = 0x00004000
  m_cfmprotrom  (RX) : ORIGIN = 0x00000400, LENGTH = 0x00000010
}

Now my SRAM is in one nice and large memory area. And this will hep me with the Micro Trace Buffer support, which is the next topic.

Micro Trace Buffer in Linker File

The other change is that Processor Expert adds the following to support the Micro Trace Buffer:

/* reserve MTB memory at the beginning of m_data */
.mtb : /* MTB buffer address as defined by the hardware */
{
  . = ALIGN(8);
  _mtb_start = .;
  KEEP(*(.mtb_buf)) /* need to KEEP Micro Trace Buffer as not referenced by application */
  . = ALIGN(8);
  _mtb_end = .;
} > m_data

💡 The KEEP GNU gcc linker directive is needed to avoid that the linker dead-strips that buffer from my application. Usually the linker will remove any variables which are not used. That trace buffer is not used by the application, but it is used by the trace feature in the debugger. As such, the KEEP directive tells the linker to keep it. Don’t worry that it will occupy SRAM if not used: if not used, that buffer size will be zero (more on this below).

Recreating the linker file with Processor Expert adds the above section. If I have switched off linker file creation, then I should add the above part to my linker file. More about why such an entry is needed in the next paragraph…

Micro Trace Buffer Support

One of the greatest added features in MCU10.3 is the ability to trace my application with a MTB (Micro Trace Buffer). For this there is a setting in the Debug/Launch configuration:

Enable Trace And Profile

Enable Trace And Profile

In order to have this functionality working, it needs a software buffer in RAM. That’s what has been added as .mtb in the linker file (see above). Projects created with MCU10.3 add that trace buffer to the sources:

sa_mtb.c in project

sa_mtb.c in project

To enable trace support for 10.3 beta project, that file has to be added. This can be done with creating a new project with 10.3 and then copy that file over, or simply create a new file sa_mtb.c with following content:

/*
* sa_mtb.c
*
*  Contains the definition of the buffer used for allocating SRAM space for the MTB trace.
*/

#if (defined(__SA_MTB_SIZE) && (__SA_MTB_SIZE > 0))
/*
* MTB (Micro Trace Buffer) is using its own section name, which is used in the linker script.
*/

#define SA_MTB_ALIGNEMENT  64  /* alignment of the MTB buffer */

unsigned char __attribute__((section (".mtb_buf"))) mtb_buf[__SA_MTB_SIZE] __attribute__ ((aligned (SA_MTB_ALIGNEMENT)));

#endif  /* __SA_MTB_SIZE */

If I enable trace, then it will tell me to rebuild my project:

Trace Enabled. Please rebuild the project

Trace Enabled. Please rebuild the project

The reason is, it has set a define in the compiler setting with the trace buffer size:

__SA_MTB_SIZE defined in the GCC Preprocessor Settings

__SA_MTB_SIZE defined in the GCC Preprocessor Settings

NOTE:  If I enable trace through Project Properties > Run/Debug Settings, then the compiler define does not get properly set. But it works if I do it through the menu Run > Debug Configurations.

Summary

To take advantage of MCU10.3, two simple things are needed for my beta projects: Resetting the linker memory map and to add the sa_mtb.c file to my project. With this I have the advantage of a simpler memory map, plus I can use the hardware trace functionality. How to use the MTB will be a topic in one of my next posts.

The Freedom FRDM-KL25Z projects I have made available here are already migrated.

Happy migrating 🙂

5 thoughts on “Migrating Kinetis-L Projects from Beta to Final MCU 10.3

  1. Hi,

    Will the ‘Special Edition’ work for all the examples in these articles ?

    Also, How much is the Code size limitation ? The product page does not mention any figure.

    Thanks !

    Like

  2. Pingback: Debugging ARM Cortex-M0+ Hard Fault with MTB Trace | MCU on Eclipse

What do you think?

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.