topic Re: Can I use both flash banks in LPC18S37? in LPC Microcontrollers

Can I use both flash banks in LPC18S37?

nxp68994 — Thu, 28 Mar 2019 09:34:02 GMT

The LPC18S37 has two flash banks A and B. Usually flash bank A is used for downloading and booting. As I understand the user manual, both flash banks cannot not be used simultaneously, but code which is stored in bank B can be called from code in bank A.

Now I come to my question: does MCUXpresso IDE support distributed code in both flash banks? Or must I define my own jump table in bank B to reach function from bank A?

Thanks in advance

Re: Can I use both flash banks in LPC18S37?

soledad — Thu, 28 Mar 2019 19:38:50 GMT

Hi,

A number of LPC18/43 parts provide dual banks of internal Flash, with bank A starting at address 0x1A000000, and bank B starting at address 0x1B000000.

* LPC18x3/LPC43x3 : Flash = 2x 256KB (512 KB total)
* LPC18x5/LPC43x5 : Flash = 2x 384KB (768 KB total)
* LPC18x7/LPC43x7 : Flash = 2x 512KB ( 1 MB total)

When you create a new project using the New Project Wizard for one of these parts, an appropriate default Flash driver (from LPC18x3_43x3_2x256_BootA.cfx /LPC18x5_43x5_2x384_BootA.cfx /LPC18x7_43x7_2x512_BootA.cfx) will be selected which after programming the part will also configure it to boot from Bank A Flash.
If you wish to boot from Bank B Flash instead, then you will need to manually configure the project to use the corresponding “BootB” Flash driver ( LPC18x3_43x3_2x256_BootB.cfx /LPC18x5_43x5_2x384_BootB.cfx / LPC18x7_43x7_2x512_BootB.cfx). This can be done by selecting the appropriate driver file in the “Flash driver” field of the Memory Configuration Editor.
Note: you will also need to delete Flash Bank A from the list of available memories (or at least reorder so that Flash Bank B is first).

In addition MCUXpresso IDE provides a number of mechanisms to allow you to do this whilst still being able to use the managed linker script mechanism. These include:
• Changing the layout and order of memory using the Memory Configuration Editor
• Changing the size and location of the stack and heap using the Heap and Stack Editor
• Decorating the definitions of variables and functions in your source code with macros from the cr_section_macros.h to cause them to be placed into different memory blocks

• Providing project specific versions of FreeMarker linker script templates to change particular
aspects of how the managed linker script mechanism creates the final linker script

Please check more information about how to use the Memory Configuration Editor in chapter 16.8 of the attached user guide.

I hope this helps.

Have a nice day!

Sol

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

Re: Can I use both flash banks in LPC18S37?

nxp68994 — Fri, 29 Mar 2019 13:40:00 GMT

Hi Sol,

Thank you for the answer. Please let me specify what I want. The default setting is perfect, put code into Flash bank A and boot from bank A. I will not change it. Also the default memory setting is fine. My question was, how can I use bank B additionally?

As I understand LPC flash memory organization it is not possible to use both flash banks as entire flash memory. I can only use one bank at a time, either A or B.

Booting and startup code should stay in bank A and I want to put a large library in bank B. Can I put all code into one project and define the startup code as “put it into bank A” and the library code as “put it into bank B”? Or must I broke the project into two parts?

I never found settings in MCUXpresso which allowing that, therefore I assume I must broke my project in two parts. Let say I put the library with a jump table at top into bank B and allow from defined addresses from bank B via 0x1B000000 + offset -> jumps into library code. Then I must put a “jump function” in bank A which branches to the table in bank B to call a “bank B function”. With this mechanism I can call functions in bank B from bank A.

At the end my question: do you know MCUXpresso allows an easier way to realize it as my “jump table mechanism”?

Sorry for my comprehensive question,
thank you in advance

Re: Can I use both flash banks in LPC18S37?

soledad — Fri, 05 Apr 2019 16:51:10 GMT

Please check the 16.13.2 section of the user manual, this section may help.

16.13.2 Configuring projects to span multiple Flash Devices
Most MCUs only have one bank of Flash memory. But with some parts more than one bank may
be available – and in such cases, by default, the managed linker script mechanism will still place
all of the application code and rodata (consts) into the first bank of Flash (as displayed in the
Memory Configuration Editor)..
For example
• most of the LPC18 and LPC43xx parts containing internal Flash (such as LPC1857 and
LPC4357) actually provide dual banks of Flash.
• some MCUs have the ability to access external Flash (typically SPIFI) as well as their built-in
internal Flash (e.g. LPC18xx, LPC40xx, LPC43xx, LPC546xx).
The macros provided in the “cr_section_macros.h” header file provide some ability to control the
placement of specific functions or rodata items into the second (or even third) bank of Flash.
However the use of FreeMarker linkers script templates allow this to be done in a much more
powerful and flexible way.
One typical use case for this is a project which stores its main code and data in internal Flash,
but additional rodata (for example graphics data for displaying on an LCD) in the external SPIFI
Flash.
For instance, consider an example project where such rodata is all contained in a set of specific
files, which we therefore want to place into the external Flash device. One very simple way to do
this is to place such source files into a separate source folder within your project. You can then
supply linker script templates to place the code and rodata from these files into the appropriate
Flash.
For example, for a project using the LPC4337 with two internal Flash banks, plus external SPIFI
Flash, if the source folder used for this purpose were called ‘spifidata’, then placing the following
files into a linkscripts directory within your project would have the desired effect:

text.ldt
<#if memory.alias=="Flash3">
*spifidata/*(.text*)
</#if>
*(.text_${memory.alias}*) /* for compatibility with previous releases */
*(.text_${memory.name}*) /* for compatibility with previous releases */
*(.text.$${memory.alias}*)
*(.text.$${memory.name}*)
rodata.ldt
<#if memory.alias=="Flash3">
*spifidata/*(.rodata*)
</#if>
*(rodata.$${memory.alias}*)
*(rodata.$${memory.name}*)

Note: the check of the memory.alias being Flash3 is to prevent the code/rodata items from ending
up in the BankB Flash bank (which is Flash2 by default).

I hope this helps,

Have a nice day!

Sol

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!

Re: Can I use both flash banks in LPC18S37?

nxp68994 — Tue, 23 Apr 2019 12:32:30 GMT

Hi Sol,

Thank you for the explanation. With the ability to modify the generation of linker scripts brings a great flexibility. A lot of the files *.ldt in folder …\ide\Wizards\linker are used to prepare the linker setup. Is there a small example how to include an own ldt file? Let say I write my own “flash2.ldt” where the linker statements for the Flash B are defined.

I would define a custom section for code for flash bank B:

void foo() __attribute__((section(".text_flashB")));

....

void foo() {}

The file “flash2.ldt” generate the linker statements to include “.text_flashB” code content into section of flash bank B. I ask myself, how the ldt-file is loaded (automatically?) and where do I find examples of FreeMarker code snippets used by MCUxpresso?

I could imagine that this is a normal use-case for professional LPC18xx projects where the entire flash memory must be used. Do you know about such example?

I know, my question is a little bit ambitious and brings you into your maximum load limit. Sorry for that!

Anyhow, thank you for the help and useful answers so far!

Re: Can I use both flash banks in LPC18S37?

soledad — Thu, 25 Apr 2019 17:02:27 GMT

Hi,

Please let me know if the following information helps,

17.12 FreeMarker Linker Script Templates
By default, MCUXpresso IDE projects use a managed linker script mechanism which
automatically generates a linker script file without user intervention – allowing the project code
and data to be laid out in memory based on the IDE’s knowledge of the memory layout of the
target MCU.
However sometimes the linker script generated in this way may not provide exactly the memory
layout required. MCUXpresso IDE therefore provides a highly flexible and powerful linker script
template mechanism to allow the user to change the content of the linker script generated by
the managed linker script mechanism
17.12.1 Basics
FreeMarker is a template engine: a generic tool to generate text output (HTML web pages, emails,
configuration files, source code, etc.) based on templates and changing data. Built into
MCUXpresso IDE are a set of templates that are processed by the FreeMarker template engine
to create the linker script. Templates are written in the FreeMarker Template Language (FTL),
which is a simple, specialized language, not a full-blown programming language like PHP. Full
documentation for FreeMarker can be found at http://freemarker.org/docs/index.html .
MCUXpresso IDE automatically invokes FreeMarker, passing it a data model that describes
the memory layout of the target together with a ‘root’ template that is processed to create the
linker script. This root template, #includes further ‘component’ templates. This structure allows
a linker script to be broken down into various components, and allows a user to provide their
own templates for a component, instead of having to (re-)write the whole template. For example,
component templates are provided for text, data and bss sections, allowing the user to provide a
different implementations as necessary, but leaving the other parts of the linker script untouched.

17.12.2 Reference
FreeMarker reads input files, copying text and processing FreeMarker directives and ‘variables’,
and writes an output file. As used by the MCUXpresso IDE managed linker script mechanism,
the input files describe the various components of a linker script which, together with variables

defined by the IDE, are used to generate a complete linker script. Any of the component template
input files may be overridden by providing a local version in the project.
The component template input files are provided as a hierarchy, shown below, where each file
#includes those files nested below. This allows for individual components of the linker script to be
overridden without having to supply the entire linker script, increasing flexibility, while maintaining
the benefits of Managed Linker Scripts.
Linker script template hierarchy
linkscript.ldt (top level)
• user.ldt (an empty file designed to be overridden by users that is included in linkscript, memory
and library templates)
• user_linkscript.ldt (an empty file designed to be overridden by users that is included in linkscript
only)
• linkscript_common.ldt (root for main content)
• header.ldt (the header for scripts)
• listvars.ldt (a script to output a list of all predefined variables available to the template)
• includes.ldt (includes the memory and library scripts)
• section_top.ldt (top of the linker script SECTION directive)
• text_section.ldt (text sections for each secondary Flash)
• text_section_multicore.ldt (text sections for multicore targets)
• extrasections_text.ldt (additional sections specified in Properties – Managed Linker Script
pane)
• text.ldt (for inserting *text)
• extrasections_rodata.ldt (additional sections specified in Properties – Managed Linker
Script pane)
• rodata.ldt (for inserting rodata)
• boot_hdr.ldt (allows placement of optional header before main code section)
• boot_hdr_partfamily.ldt
• main_text_section.ldt (the primary text section)
• global_section_table.ldt (the global section table)
• crp.ldt (the CRP information)
• extrasections_text.ldt (additional sections specified in Properties – Managed Linker Script
pane)
• main_text.ldt (for inserting *text)
• extrasections_rodata.ldt (additional sections specified in Properties – Managed Linker
Script pane)
• main_rodata.ldt (read-only data)
• cpp_info.ldt (additional C++ requirements)
• exdata.ldt (the exdata sections)
• end_text.ldt (end of text marker)
• usb_ram_section.ldt (placement of SDK USB data structures)
• stack_heap_sdk_start.ldt (placement of MCUXpresso style heap/stack)
• data_section.ldt (data sections for secondary ram)
• data_section_multicore.ldt (data sections for multicore targets)
• extrasections_data.ldt (additional sections specified in Properties – Managed Linker Script
pane)
• data.ldt (for inserting *data)
• mtb_default_section.ldt (special section for MTB (cortex-m0+ targets)
• uninit_reserved_section.ldt (uninitialised data)
• main_data_section.ldt primary data section)
• extrasections_data.ldt (additional sections specified in Properties – Managed Linker Script
pane)

• main_data.ldt (for inserting *data)
• bss_section.ldt (secondary bss sections)
• extrasections_bss.ldt (additional sections specified in Properties – Managed Linker Script
pane)
• bss.ldt (for inserting *bss)
• main_bss_section.ldt primary bss section)
• extrasections_bss.ldt (additional sections specified in Properties – Managed Linker Script
pane)
• main_bss.ldt (for inserting *bss)
• noinit_section.ldt (no-init data)
• extrasections_noninit.ldt (additional sections specified in Properties – Managed Linker
Script pane)
• noinit_noload_section.ldt (no-load data)
• stack_heap_sdk_postdata.ldt (placement of MCUXpresso style heap/stack)
• stack_heap_sdk_end.ldt (placement of MCUXpresso style heap/stack)
• stack_heap.ldt (define the stack and heap)
• checksum.ldt (create the LPC checksum)
• image_size.ldt (provide basic symbols giving location and size of image)
• symbols.ldt (provide additional symbols needed to built image)
• symbols_partfamily.ldt
• section_tail.ldt (immediately before the send of linker SECTION directive)
library.ldt (the standard libraries used in the application)
• user.ldt (an empty file designed to be overridden by users that is included in linkscript, memory
and library templates)
• user_library.ldt (an empty file designed to be overridden by users that is included in library only)
memory.ldt (the memory map)
• user.ldt (an empty file designed to be overridden by users that is included in linkscript, memory
and library templates)
• user_memory.ldt (an empty file designed to be overridden by users that is included in memory
only)
Linker script search paths
Whenever a linker script template is used, MCUXpresso IDE will search in the following locations,
in the order shown:
• project/linkscripts
• the searchPath global variable
• The searchPath can be set in a script by using the syntax <#global searchPath=“c:/windows/
path;d:/another/windows/path”>
• each directory to search is separated by a semicolon ';'
• mcuxpresso_install_dir/ide/Data/Linkscripts
• linker templates can be placed in this directory to override the default templates for an entire
installation
• MCUXpresso IDE internally provided templates (not directly visible to users)
Thus, a project can simply override any template by simply creating a linkscript directory within
the project and placing the appropriate template in there. Using the special syntax “super@” an
overridden template can reference a file from the next level of the search path
e.g. <#include “super@user.ldt”>

script templates
Copies of the default linker script templates used within MCUXpresso IDE can be found in the
Wizards/linker directory within the MCUXpresso IDE install. These can be used as the basis of
any project local scripts you wish to write.
Predefined variables (macros)
List (sequence) variables (used in #list)
libraries[]
• list of the libraries to be included in the “lib” script
• for example (Redlib nohost)
libraries[0]=libcr_c.a
libraries[1]=libcr_eabihelpers.a
configMemory[]
• list of each memory region defined in the memory map for the project. Each entry has the
following fields defined
• name – the name of the memory region
• alias – the alias of the memory region
• location – the base address of the memory
• size – the size of the memory region
• sizek – the printable size of the memory region in k or M
• mcuPattern
• defaultRAM – boolean indicating if this is the default RAM region
• defaultFlash – boolean indication if this is the default Flash region
• RAM – boolean indicating if this is RAM
• Flash – boolean indicating if this is Flash
for example:
configMemory[0]= name=MFlashA512 alias=Flash location=0x1a000000
size=0x80000 sizek=512K bytes mcuPattern=Flash flash=true RAM=false
defaultFlash=true defaultRAM=false
configMemory[2]= name=RamLoc32 alias=RAM location=0x10000000
size=0x8000 sizek=32K bytes mcuPattern=RAM flash=false RAM=true
defaultFlash=false defaultRAM=true
Slaves[]
• list of the Slaves in a Multicore project. This variable is only defined in Multicore projects. Each
entry has the following fields defined
• name – name of the Slave
• enabled – boolean indicating if this Slave is enabled
• objPath – path to the object file for the Slave image
• linkSection – name of the section this Slave is to be linked in
• runtimeSection
• textSection – name of the text section
• textSectionNormalized – normalized name of the text section
• dataStartSymbol – name of the Symbol defining the start of the data

• dataEndSymbol – name of the Symbol defining the end of the data
for example:
slaves[0] = name=M0APP objectPath=${workspace_loc:/MCB4357_Blinky_DualM0/Debug
/MCB4357_Blinky_DualM0.axf.o}linkSection=Flash2 runtimeSection= textSection=
.core_m0app textSectionNormalized=_core_m0appdata StartSymbol=__start_data
dataEndSymbol=__end_data enabled=true;</notextile>
Simple variables include:
• CODE – name of the memory region to place the default code (text) section
• CRP_ADDRESS – location of the Code Read Protect value
• DATA – name of the memory region to place the default data section
• LINK_TO_RAM – value of the “Link to RAM” linker option
• STACK_OFFSET – value of the Stack Offset linker option
• FLASHn – defined for each FLASH memory
• RAMn – defined for each RAM memory
• basename – internal name of the process
• bss_align – alignment for .bss sections
• buildConfig – the name of the configuration being built
• chipFamily – the chip family
• chipName – name of the target chip
• data_align – alignment for .data section
• date – date string
• heap_symbol – name of the symbol used to define the heap
• isCppProject – boolean indicating if this is a C++ project
• isSlave – boolean indicating if this target is a slave – true iff is a slave core in a multicore system
• library_include – name of the library include file
• libtype – C library type
• memory_include – name of the memory include file
• mtb_supported – boolean indicating if mtb is supported for this target
• numCores – number of cores in this target
• procName – the name of the target processor
• project – the name of the project
• script – name of the script file
• slaveName – is the name of the slave (only present for slaves)
• stack_section – the name of the section where the stack is to be placed
• start_symbol – the name of the start symbol (entry point)
• scriptType – the type of script being generated (one of “script”, “memory”, or “library”)
• text_align – alignment for .text section
• version – product version string
• workspace_loc – workspace directory
• year – the year (extracted from the date)
Extended variables
Two ‘extended’ variables are available:
environment
• The environment variable makes the host Operating System environment variables available.
For example, the Path variable is available as ${environment[“Path”]}.
Note Environment variables are case sensitive.

systemProperties
• The Java system properties are available through the systemProperties variable. For example
the “os.name” system property is available as ${systemProperties[“os.name”]}. Note: System
properties are case sensitive.
Outputting variables
A list of all predefined variables and their values can be output to the generated linker script
by setting the Preference: MCUXpresso IDE -> Default Tool settings -> … and list predefined
variables in the script
A list of extended variables and their values can be output to the generated linker script by
creating a linkscripts/user.ldt file in the project with the content
<#assign listvarsext=true>
(This is likely to be used less often, hence the slightly longer winded method of specifying the
option)

Re: Can I use both flash banks in LPC18S37?

converse — Thu, 25 Apr 2019 18:06:19 GMT

You do not need to modify the linker script in anyway to add code to a specific section. The standard script will do this.

read chapter 17 of the user manual.

https://www.nxp.com/docs/en/user-guide/MCUXpresso_IDE_User_Guide.pdf

Especially 17.8 and 17.11.

Re: Can I use both flash banks in LPC18S37?

nxp68994 — Mon, 06 May 2019 12:03:45 GMT

Hi Soledad and Con Verse,

Thank you for the very detailed and helpful explanation! I will study it accurately.

By Wolf