Dear Alice,
Thanks for your help and investigation but I can't repeat your success on my side.
The m4 works, but the m0 didn't, which is the same as what I have before. After playing more rounds, even m4 not working every time. After debugging by adding m4.axf to "Other Symbols" of the Debug configuration, found that the volatile int in m4 being overwritten with strange value. I will try to learn how to use other memory segment for volatile variables.
A good new to share. Among these two weeks I have created a dual core SBL by linking an empty slave with the SBL master. While flashing user application through IAP, I keep the size and flash memory location of the m0.bin so that when SBL do a "normal" boot, it's the SBL to memcpy() the m0.bin to 0x20010000, and then it's the SBL calling boot_multicore_slave() to start the m0+ core, and finally SBL calling the boot_jump() to m4.bin. That means the m0+ core is started by the SBL, not by the user application after boot_jump().
This might be more troublesome because I cannot use the .bin file generated with both m4 and m0 by the IDE but it's so far repeatably stable. The only thing to note so far is that the Chip_PININT_Init(LPC_PININT) need to be called by SBL instead of m4 nor m0 because it's not only enable the PININT but also RESET the PININT. Additional PinMux, SetPinDIR, configure PININT, EnableIRQ, UART_Init, etc are still good leaving in m4.bin and m0.bin.
Many Thanks again for your investigation, and I will leave more time to redo this again targets to flash the dual core .bin build from IDE as a flashing target in the next project.
Best Regards,
Ken