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:

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.

This triggers a confirmation dialog:

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:

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:

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:

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

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 🙂