LPC54114 dual-core example ... take 2

[klausrschambeck]

this is in response to the original LPC54114 dual-core example which, to me, didn't provide a working solution for an nxp chip with the nxp mcuxpresso ide (i'm neither a keil nor an iar guy)

here is a link to the original post (not from me)

LPC54114 dual-core example 

sorry, i complained already before and her is the take 2 approach for mcuxpresso fans with a hang for C++

and finally i was able to attach the zippie ... let's hope it works for you as it did for me

sorry for the maybe a bit unusual format, but i started with the lpc54114 flavor and the sdk on mcuxpresso on my birthday july 25 and spent until today aug 8 to get my very own serial code with fifo, which i'm using for 10 plus years, to work along with a, to me new, dual core concept ... why does this simple stuff take so wonderfully (wanted to start with and f...) long ... yeah, i'm slow, but a whole bunch of info from the chip vendor was. to me, also missing in action

well ... it works now ... and thanks and a special cheers to all the contributors, Klaus

p.s. had to upload a new zippie file ... had a bad version in my 1st attempt

Original Attachment has been moved to: cortex_54114_dualcore_blinky.zip

[Carlos_Mendoza]

Hi klausrschambeck,

Thanks for the contribution!

In addition to the dual core example from the post you mention, you can also use as reference the multicore examples that come with the MCUXpresso SDK package for the LPC54114 MCUs:

Here is a document that might be useful if you want to download and review these examples:

https://community.nxp.com/docs/DOC-333304 

Hope it helps!

Best Regards,
Carlos Mendoza
Technical Support Engineer

[klausrschambeck]

thanks Carlos :

as i earlier said, i was new to the dual core concept and wanted some simple stuff to see by example how the m0 core code get's loaded and how the 2 communicate ... not just in a written concept explanation, rather with hands on code ... now what seems simpler than "hello world" and "blinky", but the blinky project wasn't in the mcuxpresso format and had a complex folder structure

one thing i also like, is to get the libraries out of the way in my projects, like in the old lpcopen approach ... therefore i created a separate lib project where i stuffed all the libraries and now the application specific part (blinky) and whatever would be part of the app, other than libs is kept together and not cluttered with the libs code

i have one more issue with nxp and mcuxpresso at this time ... i was unable to create a working, blank, empty C++ mcuxpresso sdk based project framework as outlined in my post

no startup files with new C++ lpc54114 sdk project 

and this was also one reason for me to publish my, to "C++" converted code, so that others can use it as a starting point and don't have to go through the trouble i went through

note : the startup_xxx.c needs to be renamed to startup_xxx.cpp in order for the constructors and other C++ stuff to be called and work properly

also the blinky project shows a very low level way of dealing with the dual core project as compared to the "hello world" which utilizes the "mcmgr" code to partially control of the m0 code ... therefore the blinky was more educational than the hello world example, or in a different way simply put

now that i read more on the dual core communication, started by the "mcmgr", which lead me to "erpc" and "rpmsg", i might try to examine their related dual core examples

at this point, the "mcmgr" seems a bit too complex to me for what it's doing ... the same might also apply to"erpc" and "rpmsg" (have only read about their concept) , but as i said, i need to 1st define my needs before choosing the right approach for implementation

thanks for your reply, cheers Klaus

[klausrschambeck]

well, i just discovered a small bug in the code i uploaded ... as long as it's only tested with the mcuxpresso project debug upload, everything is fine ... as soon as it's power cycled, the slave code is lost, it never made it into flash

my m0 slave project only produces an *.axf file and no axf.o file which would be needed for the master

googling for hours, the only thing i could come up with on my own was the following :

1) create a new empty m0 slave C++ project, as empty as can be, un-check everything, and filling in the pre-processor directives as described will compensate for it

2) write down the pre-processor directives, includes from the C+ and C compiler, as well as the linker library settings from my org project and create the same settings in the newly created empty project

3) create the missing directories from my org project in the new one with new->source-folder and copy my files into them

4) delete the files in the new "source" folder and copy the ones from my org project into it as well as copy my startup files into the new startup folder

5) this should do it for the m0 slave part and an *.axf.o file should now be created after "project-build" in the debug folder

the m4 master part has a similar issue, that it doesn't copy the *.axf.o file into the project ... changing the property->settings->linker->multicore multicore-slaves is supposed to do it, but it didn't

therefore, repeat of the actions from above, and creating a new empty m4 master C++ project and continuing with the above mentioned steps should work ... yes when creating the new project, don't hit "final", go for the "next" choice and specify the location of the m0 slave project

this did it for me ...

since i couldn't find a way in mcuxpresso to create a working new C++ project (the startup files are missing), the above method of creating it and later copying my startup files into the startup folder does the trick

basically the startup files are identical to a newly created "C" project and can be used in a new "C++" project, which also enables the C++ compiles settings ... do not forget to rename the startup_xxx.c file to *.cpp, otherwise the C++ constructors and more will not work

sorry for me being lazy and not providing a corrected example, but the description above might be better for people to do some hands on work and understand some of the mechanics behind it ... again, sorry for me being lazy

cheers, Klaus