Dual-core examples using IAR

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Dual-core examples using IAR

2,470 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by DT1 on Tue Mar 25 13:18:51 MST 2014
Hi,

I'm desperatly looking for working dual-core examples for IAR (and not Keil!). Note that I don't want to use LPCOpen, my application is really far in developpement using the simple LPC43xx Periph library (which is perfect for me) and I don't want to introduce LPCOpen in that project.

I'm asking because I can't seem to be able to build my application using the ipc stuff from the LPC43xx Periph library.

Any suggestions?

Thanks!!!
Labels (1)
0 Kudos
14 Replies

1,662 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by bavarian on Thu Apr 07 10:23:37 MST 2016
I think you refer to the Basic_3core example attched to this thread. I need to admit that it's not useful for the LPC4370, as I had a triple-core test chip with flash available :-)
But it is easy to port it to the flashless chip.

For all 3 cores there is a standalone project. Of course there is a relationship between these projects to avoid resource conflicts.

[list=1]
  [*]  Port the M4 project from flash bank #A to SPIFI. This means that you link it to address 0x1400 0000.
  [*]  Port the M4a project from flash bank #B to SPIFI. This means that you link ito e.g. to address 0x1401 0000.
  [*]  The M0s project does not need to be ported, it runs from its internal SRAM memory area. The result of the compilation goes in to the M4 project folder. Please compile M0s, then M0a and then the M4 project.
[/list]

I did these linker changes for you, but did not test it on a Link2 board (yet). Of course as it runs now from SPIFI and not from 2 different internal flash banks, the system init code should change a little bit as well (but mustn't). The access to the SPIFI from two bus masters will also kill the performance of the SPIFI (flash cache get's more or less useless), so this memory setup is not a real use case, but it should work. M4 from SPIFI, M0a and M0s from SRAM would be one possible setup.

Regards,
NXP Support Team
0 Kudos

1,662 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by prasannacn336 on Sat Apr 02 07:22:43 MST 2016
sir i have tried same  programme in lpc-link2 (lpc4370) board using keil 5.plz explain how to change the settings.and how to know both processors are work in simultaneously..i have able to write a program in M4. but in the  above program  plz explain how to make the set up for lpc4370(flashless).
0 Kudos

1,662 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by DT1 on Mon Apr 07 10:57:53 MST 2014
Thanks a lot for your answer. I think I now have the tools to make this work :)

A side question on the same topic. I guess that one easy way to avoid all this would be to simply include the M0 code into my M4 application (like the examples). At first I didn't want to do this cause I was under the impression both applications would be too big, but in the end, my M0 app is quite small.

Using IAR, what's the best way to convert the output of my M0 project into a .c file that will be included in the M4 application and programmed using the "IPC_downloadSlaveImage" API function?

Thanks again!
0 Kudos

1,662 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by bavarian on Thu Apr 03 05:05:18 MST 2014
Now we enter the expert level   8-)

[list]
  [*]  Programming code into a flash means in our case that you download a small loader application via JTAG or SWD to the ARM core and let this loader manage the transfer and the programming of the data.
  [*]  But this means that this ARM core must be operational. Which is not (always) the case for the M0 inside LPC4300. This was also the key point for the problems with the debugger.
  [*]  Programming the M0 code into the flash using the M0 works fine, as long as you do it at the right point in time (when the M0 is in a good mood)
  [*]  This characteristic is the same for Keil uVision and other toolchains
[/list]

So, what to do now in reality to flash the M0 code with the debugger configured to M0:
[list]
  [*]  Use a debugger which supports a JTAG connection without giving a [u]hardware[/u] reset to the target (I-jet, CMSIS-DAP, J-Link). This ensures that an enabled M0 is not forced back to reset state by a chip reset event.
  [*]  Place the point in time where you start the flash programming into the delay loop running on the M0. However you do this, implement some LED indicators, simply make it long enough etc.
[/list]

If you want to optimize it, then you could do the following:
[list]
  [*]  Let the debugger generate a reset
  [*]  Measure somehow the time between the reset and the first attempts of the debugger to catch the M0 core (or do try & error)
  [*]  After reset the M4 starts over and finally starts the M0, make sure that the first access of the debugger happens when the M0 is already up and running (e.g. in the delay loop)
  [*]  Some debuggers have a configuration setting for the period between reset and first actions
  [*]  When done freeze your environment
[/list]


Regards,
NXP Support Team
0 Kudos

1,662 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by DT1 on Fri Mar 28 08:13:34 MST 2014
Just tried to dual-debug and it works great, but only if I send the M0 code using Segger JFlash before. After that, I start debugging on both cores and it works great.

What could be the reasons I can't download my code to the M0 core using IAR?
0 Kudos

1,662 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by DT1 on Fri Mar 28 07:14:07 MST 2014
Hi,

thanks for the answer!
Ok, I did everything I found in the document.

M4
--------------------------
- Added the time delay loop a the start of c_entry() (which is called by main() and execute before any SystemInit.
- Changed the J-Link debugger settings for the Reset, now using "Reset Pin";
- Changed the J-Link debugger settings for the JTAG speed, now using Auto with 32k initial;
- Changed the J-Link debugger settings for the SWO clock, now using not-auto and 2000k;
- Changed the J-Link debugger settings in "Connection" to scan the chain and use TAP number 0;

Trying to debug works fine. Code is sent, no errors and my debug log in IAR shows exactly the same thing as shown in the pdf.


M0
--------------------------
- Added the time delay loop a the start of c_entry() (which is called by main().
- Changed the J-Link debugger settings for the Reset, now using "Core";
- Changed the J-Link debugger settings for the JTAG speed, now using Auto with 32k initial;
- Changed the J-Link debugger settings for the SWO clock, now using not-auto and 2000k;
- Changed the J-Link debugger settings in "Connection" to scan the chain and use TAP number 1;

Trying to debug produces the same results. Here is a copy paste of the log:
Fri Mar 28, 2014 09:41:49: Loaded macro file: C:\Program Files (x86)\IAR Systems\Embedded Workbench 7.0\arm\config\debugger\NXP\Trace_LPC18xx_LPC43xx.dmac 
Fri Mar 28, 2014 09:41:49: JLINK command: ProjectFile = C:\My Project\IAR\settings\ProjM0_Flash.jlink, return = 0 
Fri Mar 28, 2014 09:41:49: JLINK command: scriptfile = C:\Program Files (x86)\IAR Systems\Embedded Workbench 7.0\arm\config\debugger\NXP\LPC4350_DebugCortexM0.JLinkScript, return = 0 
Fri Mar 28, 2014 09:41:49: Device "LPC4357_M0" selected (0 KB flash, 0 KB RAM). 
Fri Mar 28, 2014 09:41:49: DLL version: V4.82 
Fri Mar 28, 2014 09:41:49: Firmware: J-Link V9 compiled Mar 10 2014 19:02:08 
Fri Mar 28, 2014 09:41:49: JTAG speed is initially set to: 32 kHz 
Fri Mar 28, 2014 09:41:49: TotalIRLen = 8, IRPrint = 0x0011 
Fri Mar 28, 2014 09:41:49: TotalIRLen = 8, IRPrint = 0x0011 
Fri Mar 28, 2014 09:41:49: Found Cortex-M0 r0p0, Little endian. 
Fri Mar 28, 2014 09:41:49: FPUnit: 2 code (BP) slots and 0 literal slots 
Fri Mar 28, 2014 09:41:49: LPC43xx Cortex-M0 (reset): Performing core reset for Cortex-M0 co-processor. No other reset types available for this core. 
Fri Mar 28, 2014 09:41:50: J-Link script: Performing reset sequence 
Fri Mar 28, 2014 09:41:50: Hardware reset with strategy 1 was performed 
Fri Mar 28, 2014 09:41:50: Initial reset was performed 
Fri Mar 28, 2014 09:41:50: Found 2 JTAG devices, Total IRLen = 8: 
Fri Mar 28, 2014 09:41:50:  #0 Id: 0x4BA00477, IRLen:  4, IRPrint: 0x1 CoreSight JTAG-DP 
Fri Mar 28, 2014 09:41:50:  #1 Id: 0x0BA01477, IRLen:  4, IRPrint: 0x1 CoreSight SW-DP 
Fri Mar 28, 2014 09:41:50: 1912 bytes downloaded and verified (13.34 Kbytes/sec) 
Fri Mar 28, 2014 09:41:50: Warning:  
Verify error at address 0x1B000000, target byte: 0xFF, byte in file: 0x18 
Fri Mar 28, 2014 09:41:50: Warning:  
Verify error at address 0x1B000001, target byte: 0xFF, byte in file: 0x04 
...
...
Fri Mar 28, 2014 09:41:50: Warning:  
Verify error at address 0x1B0000C8, target byte: 0xFF, byte in file: 0xB1 
Fri Mar 28, 2014 09:41:50: Warning: Too many verify errors, only the first 200 are displayed 
Fri Mar 28, 2014 09:41:52: Warning: There were warnings during download, see Log Window 
Fri Mar 28, 2014 09:41:52: Loaded debugee: C:\My Project\IAR\Flash\Exe\ProjM0.out 
Fri Mar 28, 2014 09:41:52: LPC43xx Cortex-M0 (reset): Performing core reset for Cortex-M0 co-processor. No other reset types available for this core. 
Fri Mar 28, 2014 09:41:52: J-Link script: Performing reset sequence 
Fri Mar 28, 2014 09:41:52: Software reset was performed 
Fri Mar 28, 2014 09:41:52: Warning: Stack pointer is setup to incorrect alignment. Stack addr = 0xFFFFFFFF 
Fri Mar 28, 2014 09:41:52: Target reset 
Fri Mar 28, 2014 09:41:53: There were 2 warnings during the initialization of the debugging session. 



I tried to start debugging the M0 while:
- M4 debugging was started, but auto-halted at main()
- M4 debugging was running, not halted
- M4 debugging was not started.

Same results. One thing to notice is that I performed a chip erase from Segger JFlash before attempting debugging with the new projects settings.

Here is my linker script for the M0, just in case:
/*###ICF### Section handled by ICF editor, don't touch! ****/
/*-Editor annotation file-*/
/* IcfEditorFile="$TOOLKIT_DIR$\config\ide\IcfEditor\cortex_v1_0.xml" */
/*-Specials-*/
define symbol __ICFEDIT_intvec_start__ = 0x1B000000;
/*-Memory Regions-*/
define symbol __ICFEDIT_region_ROM_start__ = 0x1B0000C0;
define symbol __ICFEDIT_region_ROM_end__   = 0x1B07FFFF;
define symbol __ICFEDIT_region_RAM_start__ = 0x10080000;
define symbol __ICFEDIT_region_RAM_end__   = 0x10087FFF;
/*-Sizes-*/
define symbol __ICFEDIT_size_cstack__ = 0x400;
define symbol __ICFEDIT_size_heap__   = 0x200;
/**** End of ICF editor section. ###ICF###*/

/********** Core Shared - AHB SRAM Region 1 **********/
define symbol SHARED_RAM_start__     = 0x20007FE0;
define symbol SHARED_RAM_end__       = 0x20007FFF;

define memory mem with size = 4G;
define region ROM_region           = mem:[from __ICFEDIT_region_ROM_start__   to __ICFEDIT_region_ROM_end__];
define region RAM_region      = mem:[from __ICFEDIT_region_RAM_start__   to __ICFEDIT_region_RAM_end__];
define region SHARED_RAM_region    = mem:[from SHARED_RAM_start__             to SHARED_RAM_end__];

define block CSTACK    with alignment = 8, size = __ICFEDIT_size_cstack__   { };
define block HEAP      with alignment = 8, size = __ICFEDIT_size_heap__     { };

initialize by copy { readwrite };
do not initialize  { section .noinit };

place at address mem:__ICFEDIT_intvec_start__ { section .intvec };

place in ROM_region     { readonly };
place in RAM_region     { readwrite,
                          block CSTACK, block HEAP };
place at start of SHARED_RAM_region { section .shared_data };


I'll continue to try things in the meantime. Again, thanks a lot for your time!!
0 Kudos

1,662 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by bavarian on Fri Mar 28 02:21:58 MST 2014
Let's try to solve first the debugger configuration problem. The problem with flashing should be easier to solve, you don't need JFlash for that, it can be done directly out of EWARM.

[u]To your question how to determine which core the debugger talks to:[/u]
The 2 cores in LPC4300 could be addressed with one debugger box at the same time using two instances of a debugger software on the PC. The settings in the debugger configuration tell the hardware box which core to address.

In case of IAR EWARM this is pre-selected by "Options --> General Options --> Processor Variant / Device".
(With an individual setting in the JTAG TAP selection this could be overruled, but it would lead finally to a conflict).

[u]The steps for a successful debug session with IAR and LPC4357 are:[/u]
1)  Read the attachment to learn how to write a convenient "debuggable" code for M4 and M0
2)  Set up your debugger as described in the attachment
3)  Happy debugging


0 Kudos

1,661 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by DT1 on Wed Mar 26 11:34:50 MST 2014
Hi,

thanks for the answer. Ok, I think I'm doing the same as you do there:


Quote:


[list]
  [*]I have an M4 project with its own linker script and flash download settings for flash bank #A. It of course connects to the M4 core via JTAG, programming and debugging works without problem.
  [*]I have an M0 project with its own linker script and flash download settings for flash bank #B. It also connects to the M4 core via JTAG for programming. If I would use the M0 for programming, then I would need to have a closer look at the current state of the chip. Ensure that the M4 does not do anything on flash bank #B, connect to the chip without reset on the JTAG port etc etc. If I want to debug the M0 I change the debugger settings
[/list]



I also don't really want to debug both cores at the same time. So let's say I want to debug only the M0. My project is as you described. A standalone project with it's onw linker file (copied in a previous post) and using the Flash Bank B. The difference might be when you say that you connect via the M4 core. How can I define that? I'm using the same JLink on the same JTAG port. What are supposed to be my IAR debugger settings?

If I understand you correctly, to debug on the M0, I should probably send the code to Flash Bank B using a tool like Segger JFlash and then just start a "debug without download" process in IAR?

Thanks again !
0 Kudos

1,661 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by bavarian on Wed Mar 26 11:08:12 MST 2014
Overall the dual core or triple core setup is quite complicated when it comes to debugging & programming.

What I normally do with dual core in the LPC4357:
[list]
  [*]  I have an M4 project with its own linker script and flash download settings for flash bank #A. It of course connects to the M4 core via JTAG, programming and debugging works without problem.
  [*]  I have an M0 project with its own linker script and flash download settings for flash bank #B. It also connects to the M4 core via JTAG for programming. If I would use the M0 for programming, then I would need to have a closer look at the current state of the chip. Ensure that the M4 does not do anything on flash bank #B, connect to the chip without reset on the JTAG port etc etc. If I want to debug the M0 I change the debugger settings
[/list]

Keep the following in mind:
[list]
  [*]  After reset the M4 starts to run and sets up the M0. After a certain period both cores are running.
  [*]  If you connect with a debuuger and the debugger is doing a reset of the chip, then you are in the same situation as with a hardware button reset.
  [*]  I have a delay loop in the M4 project right at the beginning, this ensures that during this delay the debugger can connect without problem (before maybe the M0 is doing dreadful things
  [*]  I have a delay loop in the M0 project as well, this ensures that the debugger catches the M0 before it is running into real application code.
  [*]  The debugger connection to the M0 must be "silently", so no flash download (just an image download for the debugger), no reset signal (otherwise the chip starts over and the M0 is in reset for a certain period, not longer visible for the debugger on the JTAG scan chain --> crash)
  [*]  With EWARM this is all a little bit more complicated to set up, Keil uVision is much more user friendly at this point.
  [*]  Dual core debugging is possible (two debugger instances connecting via one debugger box to both cores) but most of the time this is not really useful.
[/list]

The Internet radio project (again Keil uVision  :p  )

http://www.lpcware.com/content/project/LPC4300-Internet-Radio-Demo

is a dual core project as well, turning around your setup I think. Here the M0 is doing all this boring stuff with TCP/IP and emWin, and the M4 is doing the higher sophisticated things. In this project I debugged either one or the other core, but not both at the same time.

0 Kudos

1,662 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by DT1 on Wed Mar 26 09:18:25 MST 2014

Quote: TheFallGuy
The M0 is held in reset after booting. It is up to the M4 to take the M0 out of reset. Perhaps this is your problem...



Yeah I thought about this. But my M4 application, which is programmed in the Flash Bank A, is calling this:

        IPC_haltSlave();
IPC_masterInitInterrupt(masterInterruptCallback);
IPC_startSlave();
while(intFlag != MSG_PENDING) __WFE();
IPC_resetIntFlag();


When I start to debug my M0, IAR reports the programming errors and then runs. If I halt the debugging, I see in disassembly that my M4 is looping on the "while(intFlag != MSG_PENDING) __WFE();" line.

The programming errors are bothering me and I think that my Flash Bank B is not programmed (according to the errors I get).
0 Kudos

1,662 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by TheFallGuy on Wed Mar 26 09:02:22 MST 2014
The M0 is held in reset after booting. It is up to the M4 to take the M0 out of reset. Perhaps this is your problem...
0 Kudos

1,662 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by DT1 on Wed Mar 26 08:11:15 MST 2014
When starting the debug in IAR of my Cortex M0 on the LPC4357, here is what I get :

"Warning: Stack pointer is setup to incorrect alignment. Stack addr = 0xFFFFFFFF"

Then, in the Debug Log window:

Wed Mar 26, 2014 11:04:53: Warning: 
Verify error at address 0x1B000000, target byte: 0xFF, byte in file: 0x50
Wed Mar 26, 2014 11:04:53: Warning: 
Verify error at address 0x1B000001, target byte: 0xFF, byte in file: 0x08
Wed Mar 26, 2014 11:04:53: Warning: 
...
Wed Mar 26, 2014 11:04:53: Warning: 
Verify error at address 0x1B00011C, target byte: 0xFF, byte in file: 0x01
Wed Mar 26, 2014 11:04:53: Warning: Too many verify errors, only the first 200 are displayed
Wed Mar 26, 2014 11:04:57: Warning: There were warnings during download, see Log Window


Here is my M0 linker script:
/*###ICF### Section handled by ICF editor, don't touch! ****/
/*-Editor annotation file-*/
/* IcfEditorFile="$TOOLKIT_DIR$\config\ide\IcfEditor\cortex_v1_0.xml" */
/*-Specials-*/
define symbol __ICFEDIT_intvec_start__ = 0x1B000000;
/*-Memory Regions-*/
define symbol __ICFEDIT_region_ROM_start__ = 0x1B000114;
define symbol __ICFEDIT_region_ROM_end__   = 0x1B07FFFF;
define symbol __ICFEDIT_region_RAM_start__ = 0x10080000;
define symbol __ICFEDIT_region_RAM_end__   = 0x10087FFF;
/*-Sizes-*/
define symbol __ICFEDIT_size_cstack__ = 0x800;
define symbol __ICFEDIT_size_heap__   = 0x200;
/**** End of ICF editor section. ###ICF###*/

define memory mem with size = 4G;
define region ROM_region   = mem:[from __ICFEDIT_region_ROM_start__   to __ICFEDIT_region_ROM_end__];
define region RAM_region   = mem:[from __ICFEDIT_region_RAM_start__   to __ICFEDIT_region_RAM_end__];

define block CSTACK    with alignment = 8, size = __ICFEDIT_size_cstack__   { };
define block HEAP      with alignment = 8, size = __ICFEDIT_size_heap__     { };

initialize by copy { readwrite };
do not initialize  { section .noinit };

place at address mem:__ICFEDIT_intvec_start__ { section .intvec };

place in ROM_region     { readonly };
place in RAM_region     { readwrite,
                          block CSTACK, block HEAP };


0 Kudos

1,662 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by DT1 on Wed Mar 26 07:13:17 MST 2014
Alright, I'll take a look at this, even the Keil example

Since I posted my OP, I tried some things and right now what's bugging me is that I can't even program my M0 APP on the LPC4357. In IAR, I try to start a debug and I get many downloading errors. I must have a problem my my linker scripts, but I can't find examples.

Here is my architecture:

- Custom Secondary bootloader that will implement USB and will write my M4 application to Flash Bank A and my M0 application to Flash Bank B
- M4 Application, being the main application. Large application using emWin. My linker script at moment is included below.
- M0 Application. Small one.

The custom secondary bootloader is not implemented yet, so I don't worry too much about it. But I do want to have a working dual-core setup. What do you recommand for linker scripts?
Thanks !

PS: My M4 linker:
/*###ICF### Section handled by ICF editor, don't touch! ****/
/*-Editor annotation file-*/
/* IcfEditorFile="$TOOLKIT_DIR$\config\ide\IcfEditor\cortex_v1_0.xml" */
/*-Specials-*/
define symbol __ICFEDIT_intvec_start__ = 0x1A000000;
/*-Memory Regions-*/
define symbol __ICFEDIT_region_ROM_start__ = 0x1A000114;
define symbol __ICFEDIT_region_ROM_end__   = 0x1A07FFFF;
define symbol __ICFEDIT_region_RAM_start__ = 0x10000000;
define symbol __ICFEDIT_region_RAM_end__   = 0x10007FFF;
/*-Sizes-*/
define symbol __ICFEDIT_size_cstack__ = 0x2000;
define symbol __ICFEDIT_size_heap__   = 0x4000;
/**** End of ICF editor section. ###ICF###*/

/********** Flash BankB Region **********/
define symbol __ICFEDIT_region_ROM_BANKB_start__ = 0x1B000000;
define symbol __ICFEDIT_region_ROM_BANKB_end__   = 0x1B07FFFF;

/********** Local SRAM Region **********/
define symbol LOCAL_SRAM_start__    = 0x10080000;
define symbol LOCAL_SRAM_end__      = 0x10089FFF;

/********** AHB SRAM Region 1 **********/
define symbol AHB_SRAM1_start__     = 0x20000000;
define symbol AHB_SRAM1_end__       = 0x20007FFF;

/********** AHB SRAM Region 2 **********/
define symbol AHB_SRAM2_start__     = 0x20008000;
define symbol AHB_SRAM2_end__       = 0x2000BFFF;

/********* ETB/AHB SRAM Region *********/
define symbol ETB_SRAM_start__      = 0x2000C000;
define symbol ETB_SRAM_end__        = 0x2000FFFF;

/********* CRP REGION *********/
define symbol __CRP_start__   = 0x1A0002FC;
define symbol __CRP_end__     = 0x1A0002FF;

/********* EEPROM REGION *********/
define symbol __EE_start__   = 0x20040000;
define symbol __EE_end__     = 0x20044000;

/********* External RAM REGION - SDRAM 1 *********/
define symbol _EXT_RAM_start__ = 0x28000000;
define symbol _EXT_RAM_end__ = 0x283FFFFF;

define memory mem with size = 4G;
define region ROM_region           = mem:[from __ICFEDIT_region_ROM_start__   to __ICFEDIT_region_ROM_end__] - mem:[from  __CRP_start__ to __CRP_end__];
define region ROM_BANKB_region     = mem:[from __ICFEDIT_region_ROM_BANKB_start__ to __ICFEDIT_region_ROM_BANKB_end__];
define region RAM_region           = mem:[from __ICFEDIT_region_RAM_start__   to __ICFEDIT_region_RAM_end__];
define region LOCAL_SRAM_region    = mem:[from LOCAL_SRAM_start__             to LOCAL_SRAM_end__];
define region AHB_SRAM1_region     = mem:[from AHB_SRAM1_start__              to AHB_SRAM1_end__];
define region AHB_SRAM2_region     = mem:[from AHB_SRAM2_start__              to AHB_SRAM2_end__];
define region ETB_SRAM_region      = mem:[from ETB_SRAM_start__               to ETB_SRAM_end__];
define region CRP_region           = mem:[from  __CRP_start__ to __CRP_end__];
define region EEPROM_region        = mem:[from  __EE_start__ to __EE_end__];
define region EXT_RAM_region       = mem:[from _EXT_RAM_start__ to _EXT_RAM_end__];

define block CSTACK    with alignment = 8, size = __ICFEDIT_size_cstack__   { };
define block HEAP      with alignment = 8, size = __ICFEDIT_size_heap__     { };

initialize by copy { readwrite };
do not initialize  { section .noinit };
do not initialize  { section .eeprom };

place at address mem:__ICFEDIT_intvec_start__ { section .intvec };

place in LOCAL_SRAM_region       { section .local_sram };
place at end of AHB_SRAM1_region { section .shared_data};
place in AHB_SRAM1_region        { section .ahb_sram1 };
place in AHB_SRAM2_region        { section .ahb_sram2 };
place in ETB_SRAM_region         { section .etb_sram };
place in EEPROM_region           { section .eeprom };

place at start of ROM_BANKB_region  { section .M0_CODE };

place in CRP_region              { section .crp };

place in ROM_region              { readonly };
place in RAM_region              { readwrite,
                                   block CSTACK, block HEAP };
place in EXT_RAM_region          { section GUI_RAM };
0 Kudos

1,662 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by bavarian on Wed Mar 26 06:15:02 MST 2014
If you download the examples for the NXP devices from the IAR Information Center (EWARM --> Help --> Information Center), then you will also get an example for the LPC4350 and the Hitex board which realizes a dual core setup using rather basic mechanisms.

However, I also attached a Keil project, totally ignoring your remark "and not KEIL!"    :p

It is based on the older PDL code, it's programmed quite straight forward and full of comments with regards to a triple core setup for the LPC437x device. Maybe it's useful for you to understand the setup from the MCU point of view.
For the setup of EWARM (linker scripts etc) I can only refer to the example from EWARM mentioned above and also the dual core examples from our LPCOpen package.

Regards,
NXP Support Team
0 Kudos