Hello,
We would like to ask about an issue related to NBU Core initialization while debugging a KW47 application using IAR.
Environment
- Board: Custom KW47 board
- SDK Version: 26.03.00
- IAR Embedded Workbench for ARM: 9.60.3
- Debug Probe: CMSIS-DAP
- Reset setting: Hardware Reset
- Run to: main
Screenshots of the IAR debugger configuration are attached for reference.


Observed Behavior
After performing "Download and Debug" in IAR, if we press Go without first executing a Hardware Reset, an ASSERT occurs during BLE initialization.
We traced the issue to the following call sequence:
APP_InitBle()
->PLATFORM_InitMulticore()
-> HAL_RpmsgMcmgrInit()
returns kStatus_HAL_RpmsgTimeout
-> assert(false)
However, if we perform the following sequence:
- Download and Debug
- Hardware Reset
- Go
the application starts normally and no ASSERT occurs.
Our Hypothesis
Based on the observed behavior, we suspect the following sequence may be occurring:
- Download starts.
- After the download completes, the NBU Core begins running before the debugger is fully attached.
- When the debugger attaches, the Cortex-M33 Core returns to ResetHandler.
- However, the NBU Core continues running.
- As a result, the Cortex-M33 Core and NBU Core become out of sync.
- When HAL_RpmsgMcmgrInit() is executed, the RPMsg/MCMGR initialization handshake cannot be completed, causing kStatus_HAL_RpmsgTimeout to be returned.
- After a Hardware Reset, both the Cortex-M33 Core and the NBU Core are reset, allowing initialization to complete successfully.
Questions
- Is the above understanding and hypothesis correct?
- When debugging KW47 applications with IAR, is there a recommended procedure to ensure that the Cortex-M33 Core and NBU Core are properly synchronized before starting execution?
Thank you for your support.
Best regards,
hyama