LPC54114 dual-core example

rocky_song · ‎12-28-2016

Some days before, there is a great post about LPC dual-core, LPC key feature_DualCore

This time, we show a LPC5411x based dual-core example. It shows all aspects about dual-core development, startup, communicate, sync, mutex. Enjoy it:)

After extracted the attachement, it locates at "boards\lpcxpresso54114\multicore_examples\blinky\mdk\blinky.uvmpw"

(几天前，有一个非常棒的介绍LPC 双核使用的帖子，这一次，我们再奉献给大家一个在LPC54114上双核使用的例子，展示了双核开发、启动、通信与互斥的方方面面。位于附件解压后的 .\boards\lpcxpresso54114\multicore_examples\blinky\mdk\blinky.uvmpw

enjoy it:)）。

---------------------------------------

(Below is the detail information about the demo, same as in "readme.txt")

Overview
========
The Multicore blinky demo application demonstrates how to set up projects for individual cores
on LPC5411x/10x dual-core system. In this demo, the M4 (master) releases the M0+ (slave) from the reset.
Both M0+ and M4 share a global variable who is interpreted as LED control, bit 0 for LED 1, bit 1
for LED 2, bit 2 for LED 3.
M4 side (Background):
Initialize board, application logic, and boot M0+ by setting M0+'s main stack, reset handler, and release M0+'s reset flag
Enter main loop. In main loop, M4 do below things every 20000 cycles.
1. Turn on green LED
2. Try lock the hardware mutex
3. Toggle red LED control bit, delay for sometime
4. Set M0+'s mailbox to the address of LED control variable, this will trigger M0+'s mailbox IRQ.
5. deliberately delay for a long time to simulate complex software execution.
5. Release mutex
M4 side (IRQ context)
In M4's mailbox IRQ handler (M0+ triggers it by writing non-zero to M4's mailbox),
Update LED states according to LED control variable value

M0+ side (Background)
1. After first POR or pin reset, M0+ runs M4/M0+ shared reset handler, and finds startup condition is not yet set, so go to sleep
2. After M0+ is reboot by M4 again sometime later, M4 already prepared M0+'s startup condition, so shared reset handler detect it
and jump to M0+'s app reset handler according to M4's settings
3. M0+ app's reset handler do basic initialization and jumps to M0+'s main()
4. In main(), M0+ just enables mailbox IRQ then enter main loop, the main loop is empty
M0+ side (IRQ context)
In parallel, once M4 write non-zero (in our case, the address of LED control variable) to M0+'s mailbox, M0+'s mailbox IRQ triggered. In mailbox IRQ handler:
1. Get the address of LED control variable,
2. try lock the hardware mutex, note that since M4 delibrately delay before releasing mutex, this try loop will cycle many times before successfully lock it.
3. toggles blue LED control bit , and write non-zero to M4's mailbox to trigger M4's mailbox IRQ.

Manual control
Press and hold down the SW1 button to hold M0 in reset state, release SW1 to release M0 from reset (M0 will restart).
Press and hold down SW2 button to prevent M4 from releasing hardware mutex, thus pauses the blinking
Toolchain supported
===================
- (Coming later) IAR embedded Workbench 7.80.2
- Keil MDK 5.21a

Hardware requirements
=====================
- Mini/micro USB cable
- LPCXpresso54114 board
- Personal Computer

Board settings
==============
No special settings are required.

Prepare the Demo
================
0. How to build
Open workspace (for KEIL, "boards\lpcxpresso54114\multicore_examples\blinky\mdk\blinky.uvmpw")
First build M0+ project, this will generate "core1_image.bin", which is M0+'s image bin file, M4 includes it as one assembly data section.
Then build M4 project, and download to flash.
Note: Do NOT try downloading M0+ build to flash, M0+ image is managed by M4.
1. Connect a micro USB cable between the PC host and the CMSIS DAP USB port (J7) on the board
2. (Optional) Open a serial terminal with the following settings (See Appendix A in Getting started guide for description how to determine serial port number):
- 115200 baud rate
- 8 data bits
- No parity
- One stop bit
- No flow control
3. Download the M4 project to the target board.
4. Either press the reset button on your board or launch the debugger in your IDE to begin running the demo.

Running the demo
================
After reset, the red and blue LEDs alternatively turned on and off, and green LED blink for a short time before each switch between red and blue. Green LED shows the period during which M4 holds h/w mutex. During it runs,
1. if you hold SW1 button down (M0 hold reset), the switch pauses and green LED keeps blinkying, and either red or blue LED is always on; after you release SW1, red and blue LED may turned on and off alternatively or altogether.
2. if you hold SW2 button down (M4 does not unlock mutex), the blink is all paused, after you release SW2, the blink resumes like before.
If you connect serial terminal, trace logs will be printed when you have button actions and when M4 take/give h/w mutex.

Customization options
=====================

zhouli · ‎05-08-2017

Thank you very much

klausrschambeck · ‎08-05-2017

thanks for the project, but i have a few questions

1) this is an nxp chip and why can't i find any connections or project files which would allow me to import it easily into my mcuxpresso work-space and have a working environment to begin learning from

2) for me, i create one project for a particular chip and then i usually leverage off this for other projects for the same chip ... therefore i'm not too experienced with shoehorning some existing code into mcuxpresso if it's not already in mcuxpresso format

3) item 2 is especially important for people who do not have multi core project experiences on how to setup these 2 projects (master, slave)

sorry, but instead of getting a head start, based upon a working mcuxpresso project for an nxp chip, i am now allowed to waste a lot of additional time to mix and match an existing mcuxpresso with your, undoubtedly working code to create something which might not work at the beginning due to unfamiliarity of multi core projects and the therefore resulting project creation errors

klausrschambeck · ‎08-06-2017

created m4 master and m0 slave C project in mcuxpresso and the empty projects compile, except a few, what seems to be, slave related addr defs in the m4 master project ... had hoped they go away when i put the blinky m4 master and m0 slave code into these empty projects

a few hours later i replaced the default m4 and m0 .c .h files and got lot's of "unresolved" and "not found" errors, mostly what seemed to be related to the lack of mcuxpresso type pre-defines

i give up for now ... it shows at least to me as an mcuxpresso user for years that this multicore example project is really not ready for prime-time with the NXP MCUXPRESSO IDE

to me an example should provide a working environment setup along with the example code functionality ... and as the cpu is from nxp i would expect that the home-grown nxp mcuxpresso ide is supported ... doesn't seem the case ... sorry

well NXP where to go from here ???

klausrschambeck · ‎08-06-2017

finally i have it sort of working ... it doesn't do exactly what the readme says ... but the leds flash and a whole bunch of "m4 took mutex" / m4 relesed mutex" messages show up ... good enough for me to prove the global part of the concept ... yes it compiles and runs as compared to before in the mcuxpresso ide

how did i get there ... moderately easy and not counting the hours, i took the multi-core hello world sdk example and cleaned it up to a point, that it was usable to me ... this means in my project is only my code, period, everything else, like the sdk, is in a library ... yes, i need two of them, even containing everything over again, m4 and m0 together, times 2, one for the m4 cortex code flavor and one for the m0 code flavor ... sorry but mcuxpresso doesn't seem to reach out of its workspace, except for inlude .h

once i had this working i made sure that all the sdk crap (files as a better word) are the same for the hello world and the blinky ... now i replaced the hello world *.c with the blinky *.c source files and everything started to work ...sort of

before i forget, i converted the whole project to C++ since we're in the 21st century, even at this low level example the only difference is the file extension

now i have to figure out how to include / attach the zippie project i made ... right now it seem i can only comment and not attach anything ... sad ... i almost sound like the donald ... really sad

i'm just a simple hw guy who does firmware for fun and i don't like to figure out all the details on how to post or attach my findings result

simonwyss · ‎08-10-2017

Thank you for your work, just drag and drop your .zip file to the online-editor. The file will then be attached.