**** Advance Notice ****

This site will be closed on 31 December 2015,

Important Information for users of NXP LPCXpresso

This site is for users of Code Red branded products.

NXP LPCXpresso users should visit the LPCXpresso FAQ's for up-to-date information relevant to that product.

Creating an LPC43xx Cortex-M4 / M0 Dual Core Application

Notes

Basic principles

When the LPC43xx comes out of reset, only the Cortex-M4 core is actually running code - the Cortex-M0 core is held in reset. When the use of the M0 core is required for a particular application, the M4 core must first set the system on, and then set up the M0APPMEMMAP register - which points to the base addresses of the M0 boot code. It can then release the M0 from reset, and the two cores are then running in parallel, but basically independently.

Creating a dual core application

A dual core application for LPC43xx is actually made up of two actual projects within your workspace, one to hold the Cortex-M4 application, and a second to hold the Cortex-M0 application. In addition because the Cortex-M4 is the master processor in the sytem, the Cortex-M4 project will also pull in a copy of the binary from the Cortex-M0 project and place this within the image generated.

To create a dual core application:

  1. Import the CMSISv2p10_LPC43xx_DriverLib and CMSISv2p10_LPC43xx_DriverLib-M0 library projects from the LPC43xx examples subdirectory of your Red Suite installation.

  2. Use the project wizard to create an "LPC4300 - C Project (Cortex-M0)" project. If your dual core application will be being downloaded and executed from flash, then you may wish to use the "External memory configuration file" option in the project wizard to setup the overall system memory map.
  3. Use the project wizard to create an "LPC4300 - C Project (Cortex-M4)" project. If your dual core project will be being downloaded and executed from flash, then you may wish to use the "External memory configuration file" option in the project wizard to setup the overall system memory map.
  4. Add a project reference from the Cortex-M4 project to the Cortex-M0 project. This will be used to help ensure that when you build the complete dual core application (which will be done via the Cortex-M4 project), it contains the latest Cortex-M0 and Cortex-M4 code.
  5. Configure the Cortex-M0 project so that the pre-build step deletes the project binary and axf files....
    rm -f "${BuildArtifactFileBaseName}.bin"; rm -f "${BuildArtifactFileName}"
  6. Configure the Cortex-M0 project so that post-build step generates a binary file (which can normally be done by simply removing the # comment in the default post-build step.)

  7. Configure the Cortex-M4 project so that the pre-build step deletes any local copies of the M0 binary and copies across the current version from the M0 project....
    rm -f M0bin/m0bin.o ; rm -f ../M0bin/CM0image.bin; cp "${workspace_loc:}/Dual4_M0/Debug/Dual4_M0.bin" ../M0bin/CM0image.bin
    Note that you will need to update the project directory and binary filename in the above example to match your actual dual core application projects.
  8. Create a new source folder in the root directory of your M4 project called "M0bin". This will be used to store the binary image of your Cortex-M0 application for incorporation into the Cortex-M4 project.
  9. Create a new assembler source file in the "M0bin" directory called "m0bin.s". Copy the below code into this file.
            .align 2
            .section ".data.$RamLoc72.CM0image"
            .global CM0image_start
            .global CM0image_end
    CM0image_start:
            .incbin "../M0bin/CM0image.bin"
    CM0image_end:

    Note that you will need to update the section name ($RamLoc72 above) to match the memory that you are actually going to run the M0 code from. Also the reason why the binary is getting placed into a .data section is that this will allow the standard data initialisation code with the startup code to actually carry out the copying of the binary from flash into the RAM memory where the M0 will run this code from.

  10. You also need to place a copy of the start_mo.c into the M0bin subdirectory. This contains the code to set up the location of the M0's vector table and release it from reset. You can take a copy of this file from the attached example.

Memory Configuration

The base address of the M0 code will be loaded by the M4 into the M0APPMEMMAP register. Code for the M0 must be built such that it is placed on a 64KB aligned address, as bits 11..0 in the M0APPMEMMAP register must be 0.

The example attached below is set up so that the M4 code will run in place from flash, but the M0 code will be relocated into the RamLoc72 region (the start of which is on a 64KB boundary). This is done automatically by the M4 startup code (as the M0 binary has been located into the data section of the M4 image).

In order to do this, the Memory Configuration Editor is used.

In the M0 project, the memory map is edited so that only the RamLoc72 region exists (ie all other regions are deleted). This will cause all of the M0 code, data, bss, heap and stack to be placed in this region.

In the M4 project, the memory map is edited so as to create the flash region where the application image will be placed. The data,bss, heap and stack will be placed automatically by the linker script so that they are in the 1st RAM region - RamLoc128. The M0 image is then located into 2nd RAM region within the M4 project - RamLoc72 - through the use of the section name used in m0bin.s (see step 9 above).

Example

zip.jpg   lpc43dualcore_simple.zip

The (very) simple dual core example targets the Hitex LPC4350 revA4 board and consists of...

To build the example, you simply need to build the required M4 project. This will automatically trigger a build of the M0 project too.

The example is set up so that the M4 code will run in place from flash, but the M0 code will be relocated into the RamLoc72 region. This is done automatically by the M4 startup code (as the M0 binary has been located into the data section of the M4 image).

Debugging

The key thing that needs to be done before debugging a dual core application is to configure the M0 project so that it does not load code to the target on connect (as this will be done via the M4 application).

To do this, right click over the M0 project in the Project Explorer view and select...

Launch Configurations -> Create Launch Configurations

Then to configure the M0 project not to load code to the target when we connect, right click on the project again and select...

Launch Configurations -> Open Launch Configurations -> Debugger

Now scroll down the list of Configuration Options listed under "Script values " and set the option "Load image" to "False".

Once you have done the above, the sequence for debugging is as follows. Note that currently (at the time of writing - Code Red IDE v4.2.3) you can only connect to either the M4 or the M0. Support for debugging both cores in parallel will be implemented in a future release of the Code Red IDE.

First of all launch a debug session for the **M4** project to download the combined M4/M0 image into flash. When you make this connection you need to make sure that you actually connect to the correct core within the MCU.

The first time you start an M4 debug session, you will receive a pop up dialog offering you a choice on two cores on the LPC43xx . Ensure that you select "Device 1" which has the TAP Id = 0x4ba00477 - which is the M4. This selection is then stored in the *.jtag file that will be placed in the Debug/Release directory. Note that you can cause the pop up dialog to reappear again by deleting the *.jtag file.

Having connected to the M4, close down the debug session.

Now launch a debug session for the **M0** project. The first time you start an M0 debug session, you will receive the JTAG selection pop up dialog again . Ensure that you select "Device 0" which has the TAP Id = 0x0ba01477 - which is the M0.

LPC43DualCoreProjects (last edited 2013-04-18 16:34:18 by CrSupportAb)