LPC55S69: Core 1 never starts despite fully verified CPBOOT/CPUCTRL/CPUCFG sequence

[ryan714]

LPC55S69: Core 1 never begins execution despite fully verified boot sequence (MCMGR and hand-written register writes both fail identically)

Environment

• Board: LPC55S69-EVK (LPCXpresso55S69), LPC55S69JBD100
• IDE: MCUXpresso IDE v25.6 [Build 136] [2025-06-27]
• OS: Linux (openSUSE)
• Toolchain: GNU ARM Embedded (bundled), GCC 14.2.1
• Debug probe: onboard LPC-Link2, LinkServer backend
• SDK components used: driver.flexcomm, driver.mailbox, middleware.multicore.mcmgr_lpc55s69, freertos_kernel + cm33_non_trustzone_port (master only)

Summary

Core 0 (master, cm33_core0) runs correctly. Core 1 (slave, cm33_core1, role M33SLAVE) never appears to execute even the first instruction of its own main(), despite every element of the boot sequence being independently verified correct at the register and memory level, across two separate clean-room project builds (one hand-written register sequence, one using NXP's own MCMGR middleware). Both attempts reach an identical dead end.

What Has Been Independently Verified Correct

Attempt 1 — Hand-written boot sequence

• SYSCON->CPBOOT set to the real, linker-confirmed address of the embedded slave image (verified via objdump -h section VMA, cross-checked against nm symbol addresses — not a symbol that resolves to 0x0, an actual non-zero embed location)
• SYSCON->CPUCTRL read back as 0x08 (bit 3 CPU1CLKEN set, bit 5 CPU1RSTEN clear) immediately after the release write, captured in-band (written into shared memory by the same function that performed the write, not read later via a possibly-stale debugger session)
• SYSCON->CPUCFG bit 2 (CPU1ENABLE) confirmed set (0x04)
• Vector table at the confirmed boot address independently verified valid: initial stack pointer computed correctly (top of Core 1's relocated SRAM region), reset vector address matches the real ResetISR symbol from nm (confirmed by disassembling the target address and finding genuine, sensible Cortex-M startup code: cpsid i → SystemInit() → data_init/bss_init loops → cpsie i → __main → _initio → application main())
• Confirmed shared-memory struct resolves to the identical physical address in both cores' independently compiled .map files
• Confirmed Core 1's private SRAM/stack region does not overlap Core 0's (relocated to a separate physical SRAM bank)
• Confirmed the embedded slave image's .data section (non-zero-initialized globals) does not land inside Core 0's live memory (required a custom linker script fragment using INSERT BEFORE .data, since the default linker script has no placement rule for the objcopy-renamed multicore section and it otherwise falls into Core 0's SRAM as an "orphan section")

Despite all of the above, a diagnostic value written as the literal first line of Core 1's main() (into memory confirmed shared and correctly addressed) never changes from its initial value.

Attempt 2 — Fresh project using NXP's mcmgr_lpc55s69 middleware

Rebuilt from scratch using MCMGR_Init() / MCMGR_StartCore() / MCMGR_TriggerEvent() instead of hand-written register writes, to rule out a mistake in our own register sequence.

• Read mcmgr_internal_core_api_lpc55s69.c directly: confirmed mcmgr_start_core_internal() performs the same CPUCFG → CPBOOT → CPUCTRL sequence, using the correct SDK macros (SYSCON_CPUCTRL_CPU1RSTEN_MASK, etc.)
• Discovered MCMGR_Init() (called from main()) does not call MCMGR_EarlyInit() / mcmgr_early_init_internal(). The latter is a separate public function whose own source comment states it is "intended to be called as close to the reset entry as possible, (within the startup sequence in SystemInitHook)" — but nothing in the generated project wires this up automatically. SystemInitHook() is __attribute__((weak)) in the generic device startup file and defaults to an empty stub.
• Added our own SystemInitHook() override on both cores calling mcmgr_early_init_internal(MCMGR_GetCurrentCore()). Confirmed via .map file that this override genuinely links in as the real function (not the weak stub) on both projects.
• Re-applied and re-confirmed every fix from Attempt 1 (embed-address stability across iterative rebuilds, .data section redirect via the same linker fragment technique, Core 1 SRAM relocation, CPUCFG/CPBOOT/CPUCTRL register values all identical to Attempt 1's results)
• MCMGR_BUSY_POLL_COUNT is undefined by default, so MCMGR_StartCore(..., kMCMGR_Start_Synchronous) blocks with no timeout at all in mcmgr.c's internal wait loop (while (s_mcmgrCoresContext[coreNum].state != kMCMGR_RunningCoreState)), confirmed by reading the macro's conditional compilation directly in mcmgr.h

Result: identical outcome. Core 0 blocks forever inside MCMGR_StartCore(). A diagnostic shared-memory value (confirmed identical address in both cores' .map files, in a genuinely shared SRAM bank, .noinit so unaffected by C-runtime init) written as literally the first executable line of Core 1's main() never leaves its initial value of 0.

Question

Given CPUCFG, CPBOOT, and CPUCTRL all read back exactly as the reference implementation (mcmgr_internal_core_api_lpc55s69.c) intends, and the embedded image at the boot address is independently confirmed to be a valid, correctly-linked Cortex-M binary — is there an additional step required to actually start Core 1's instruction fetch on this part that is not captured by these three register writes alone?

Specifically:

• Is there a known silicon errata for LPC55S69 (any revision) affecting CPBOOT/CPUCTRL-based secondary core boot?
• Does starting Core 1 genuinely require a debug-probe-level action (e.g., an SWD attach/resume specifically targeting the second SWD device enumerated on this part) in addition to the application-level register sequence? This is suggested by the fact that NXP's own multicore SDK examples (e.g. freertos_message_buffers_secondary_core), when debugged via the IDE's normal single-project "Debug" flow, appear to bring up Core 1 successfully with no separate Launch Group configuration — implying MCUXpresso's debug launch itself may be performing an additional step beyond what application code alone can trigger.
• Is there a required minimum delay, ordering constraint, or additional register (e.g. in the power/clock domain) between these three writes that isn't reflected in the reference mcmgr_internal_core_api_lpc55s69.c implementation?

Happy to provide full project files, .map files, or a minimal reproduction project on request.

[ryan714]

Update: Isolated the issue to project/linker configuration, not application code

Since posting, I ran a decisive test that narrows this down significantly.

Test: Does NXP's own unmodified multicore example work on this exact hardware?

Imported multicore_examples/hello_world (primary + secondary) for LPCXpresso55S69 fresh, completely unmodified, and debugged it as-is.

Result: it works. The onboard RGB LED blinks at a clean, regular 500ms on/500ms off rate — confirmed by comparing directly against my own project flashed onto the same board (LED off with my project, LED blinking with the unmodified example, LED off again when I re-flash my own project). This is conclusive: dual-core execution is possible on this exact board, probe, and IDE installation.

Test: Does the example's own application code work inside my project's configuration?

To isolate whether the problem was in my application code or my project's build/link configuration, I copied the working example's secondary-core main.c, app.h, and hardware_init.c verbatim (byte-for-byte, unmodified) into my own slave project, replacing my own application code entirely.

Result: the LED does not blink. Identical, unmodified NXP code that works in the original example project fails to start Core 1 when built inside my own project's configuration.

What this proves

The issue is not in application-level code (confirmed twice now - independently in a hand-written register implementation and in an MCMGR-based implementation, and now a third time with literally the example's own source files). It is something specific to how my project's Multicore linker settings / memory region configuration differs from the working example's, despite my best efforts to match it point-for-point:

• CPUCFG, CPBOOT, CPUCTRL all read back exactly as intended after MCMGR_StartCore()
• The embedded image's vector table is independently verified valid (correct stack pointer, correct reset handler address matching the real ResetISR symbol)
• Master Memory Region is set to a RAM region (not PROGRAM_FLASH), matching the working example's approach of embedding Core 1's image in RAM rather than flash
• Core 1's own private memory does not overlap Core 0's

One structural difference I've found but not yet resolved: the working example's secondary core project has no PROGRAM_FLASH memory region override at all in its .cproject (only two custom RAM-derived regions). My from-scratch wizard-created slave project has three regions including a relocated PROGRAM_FLASH. Attempting to remove that region entirely (to match the working example precisely) crashes MCUXpresso's MCU Settings page (NullPointerException: this.mcuPage is null), suggesting the IDE's tooling doesn't gracefully support a project with no flash region defined - which may itself be relevant to why matching the working example's exact configuration by hand has been difficult.

Question

Is there a specific, documented multicore project configuration (beyond what the wizard's "M33SLAVE" role + Multicore linker settings produce) required to get a from-scratch project into the same working state as the SDK's own hello_world example? Or is there a known limitation/bug in MCUXpresso IDE v25.6.136's project wizard for multicore LPC55S69 projects that the example's project files work around in a way the wizard doesn't replicate?

Happy to share both projects' complete .cproject files for direct comparison if useful.

[ryan714 · Accepted solution]

Resolved — root cause was a false negative in my own diagnostic, not a Core 1 boot failure

Posting the resolution in case anyone finds this thread later with a similar symptom.

The actual root cause

Core 1 was booting and running correctly the entire time, in every version of this project. The problem was never CPUCFG/CPBOOT/CPUCTRL, the vector table, memory placement, or anything else in the boot sequence - it was a bug in my own diagnostic instrumentation that made it look like Core 1 never executed anything.

I was using a small shared-memory struct (placed via __attribute__((section(".noinit.$SRAM4")))) written by Core 1 and read by Core 0, to observe boot progress. This technique only lands in genuinely shared memory if the project's generated linker script actually defines a region named SRAM4. My from-scratch wizard-created projects did define that region, so the technique worked there structurally - but when I later built a version on top of NXP's own working hello_world example project (which uses differently-named regions, Ram1/rpmsg_sh_mem, not SRAM4), the same attribute silently fell through to each core's own private .noinit memory instead of throwing an error. Core 0 and Core 1 were each reading/writing their own separate copy of the "shared" struct, with no compiler or linker warning that anything was wrong.

Net effect: my diagnostic reported 0 (no progress) on every single test across two independent boot implementations (hand-written CPUCFG/CPBOOT/CPUCTRL registers, and NXP's own MCMGR middleware) and multiple project configurations, because the two cores were never actually looking at the same memory address to begin with - regardless of whether Core 1 was really running.

How it was actually found

By copying NXP's working hello_world example verbatim and only adding diagnostic writes to the existing, unmodified, proven-working main.c (rather than replacing it), I could visually confirm via the onboard LED that Core 1 was genuinely executing the full sequence - yet the shared-memory counter still read 0. That contradiction (physical proof of execution vs. a diagnostic saying otherwise) was what exposed that the diagnostic itself, not Core 1, was broken. Fixing the section name to match that project's actual region (.noinit.$rpmsg_sh_mem instead of .noinit.$SRAM4) immediately produced correct, incrementing values.

Lesson for anyone else debugging multicore boot on LPC55xx

If you're using a .noinit.$<REGION_NAME> section attribute for inter-core shared memory, verify the region name against that specific project's own generated _Debug_memory.ld rather than assuming a name (like SRAM4) that worked in a different project. A mismatch here fails completely silently - no build warning, no link error, no runtime fault - and produces symptoms that look exactly like a genuine boot failure (register/vector-table-level debugging will all check out fine, because the actual problem is entirely at the diagnostic layer).

Thanks to everyone who read through the earlier posts - the CPUCFG/CPBOOT/CPUCTRL/vector-table verification work wasn't wasted; confirming all of that was correct is ultimately what forced the investigation toward the diagnostic mechanism itself as the remaining unverified piece.