LPC54114 dual-core example

Showing results for 
Search instead for 
Did you mean: 

LPC54114 dual-core example

NXP Employee
NXP Employee
0 5 2,618

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")

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