Dualcore C++ Project

lpcware · ‎06-15-2016

Content originally posted in LPCWare by MaSt on Mon Nov 04 00:20:33 MST 2013
Hi,
setting up a Dualcore C++ project i run into trouble. After sucessfully compiling both projects and linking them together into one binary, the M0 ends in the hardfault-handler with the calling of __libc_init_array(); in the generated cr_startup_lpc43xx-m0app.cpp-file:

#if defined (__cplusplus)
  //
  // Call C++ library initialisation
  //
__libc_init_array();
#endif

If i delete the __libc_init_array() call in the M0 startup-code, the application runs without problems. My assumption is, that the M0 calls the M4 __libc_init_array() and traps due M4-instruction set.

Any ideas?

lpcware · ‎06-15-2016

Content originally posted in LPCWare by qspace on Sun May 29 04:42:29 MST 2016
Sir, I have a problem with C++ dual core project on LPC4357 on LPCExpresso 8.1.4
My workspace:
+M0 core C++ project with FreeRTOS task for IPC communicate
+M4 core C project with FreeEROS task for IPC communicate
After system boot up, when I create FreeRTOS task, it pause on IntDefaultHandler on cr_startup_lpc43xx-m0app.cpp file.
So I think i has something wrong in startup code, missing Interrupt handler for FreeRTOS maybe?
FYI: I use the default startup file create by wizard.
Please check my main function on attached file!!!

lpcware · ‎06-15-2016

Content originally posted in LPCWare by MaSt on Mon Nov 04 23:23:40 MST 2013
Hi,
thanks for your help. My linker-script was ok, instead there was an uninitialized pointer in the static constructors which caused the hardfault.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by lpcxpresso-support on Mon Nov 04 07:00:18 MST 2013
Where did you enable SPFIF and copy the code? Any changes like this need to be done very early in startup.

The first part of the standard startup code is copying initial data (.data) values out of flash and into RAM, followed by clearing zero-initialised (.bss) data.

So, by the time __libc_init_array() is called, your system must be correctly configured, with the code and data configured to run in the correct place. Your hardfault is probably quite genuine because you have not set the system up correctly.

In order to do this, you are going to have to take manual control of the linker scripts, rather than using the default 'managed' linker script mechanism. A good starting point for more information is the following FAQ...

http://support.code-red-tech.com/CodeRedWiki/OwnLinkScripts

What I would suggest is defining the Flash section in the linker script in such a way that the vector table and initialisation code stays in flash, and you can then use a wildcard to place all your other text (ie code) sections into one of the RAM sections.

ie move the....

*(.text*)
*(.rodata .rodata.*)

into, say, .data_RAM2

And add " *(.text.ResetISR)" into the .text section (ie the Flash) - as you can't relocate the code that does the copying :-)

Also, please note that as you are probably going to be relocating main() into RAM the default breakpoint mechanism will not work - as it will detect that the symbol main() is in RAM, and hence use a "software breakpoint" - which will then get overwritten by the initialisation code.

Replace the default breakpoint on main() with either one on ResetISR, or else on a specific address in the initialisation code (ie still in Flash). For more details, please see:

http://support.code-red-tech.com/CodeRedWiki/InitialBP

lpcware · ‎06-15-2016

Content originally posted in LPCWare by MaSt on Mon Nov 04 06:52:44 MST 2013
I've tried this demo. [s]But it does not even start on my Hardware.[/s] I'm using a LPC4350, so i adapt the memory-configuration to run completely out of internal SRAM. [s]Unfortunately It does not even jump into reset vector after loading with debugger.[/s][EDIT] This seems to be some problem with the LPC-Link2 which makes some trouble. After switching to the "red probe +"-device this problem's gone.

In the original project i found a difference: I'm using SPFI-Flash for storing the M4-Application, after reset it copies and executes the whole application into internal SRAM. The M0-Application gets executed from SPIFI. Therefore i use a seperate Linker-script for the M4. Using the libraries given in the example provided by you

 GROUP(
 libgcc.a
 libc.a
 libstdc++.a
 libm.a
 crti.o
 crtn.o
 crtbegin.o
 crtend.o
 )

the M4 also gets a Hardfault in the moment it tries to call __libc_init_array();.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by lpcxpresso-support on Mon Nov 04 04:42:02 MST 2013
Please try downloading the attachment again

lpcware · ‎06-15-2016

Content originally posted in LPCWare by MaSt on Mon Nov 04 04:27:14 MST 2013
I'm not able to download the project, see attached screen shot.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by lpcxpresso-support on Mon Nov 04 02:40:00 MST 2013
MaSt,

I suspect there is a configuration problem in your project. If correctly configured, the m4 project will use the m4 libraries and the m0 project will use the m0 libraries.

Using the wizards, I can certainly create an m0 C++ project and an m4 C++ project (that uses the m0 project) and it works correctly. I attach the projects to this post (configured for an LPC4357).

I suggest you try this yourself, and then compare my projects with yours to see where the difference is.

p.s. Make sure you read the Multi Core FAQ at:

http://www.lpcware.com/content/faq/lpcxpresso/lpc43xx-multicore-apps

lpcware · ‎06-15-2016

Content originally posted in LPCWare by Pacman on Mon Nov 04 01:39:36 MST 2013

Quote: MaSt
If i delete the __libc_init_array() call in the M0 startup-code, the application runs without problems. My assumption is, that the M0 calls the M4 __libc_init_array() and traps due M4-instruction set.

Perhaps you only have the library as M4 native, not M0 native ?
-If you can rebuild the library, try building it for multiple architectures; eg. "universal binary", so you get a two-in-one library.
I have no idea if this will help, though.