Question Regarding HAL_RpmsgMcmgrInit() Timeout During IAR Debugging

[hyama]

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:

1. Download and Debug
2. Hardware Reset
3. Go

the application starts normally and no ASSERT occurs.

Our Hypothesis

Based on the observed behavior, we suspect the following sequence may be occurring:

1. Download starts.
2. After the download completes, the NBU Core begins running before the debugger is fully attached.
3. When the debugger attaches, the Cortex-M33 Core returns to ResetHandler.
4. However, the NBU Core continues running.
5. As a result, the Cortex-M33 Core and NBU Core become out of sync.
6. When HAL_RpmsgMcmgrInit() is executed, the RPMsg/MCMGR initialization handshake cannot be completed, causing kStatus_HAL_RpmsgTimeout to be returned.
7. After a Hardware Reset, both the Cortex-M33 Core and the NBU Core are reset, allowing initialization to complete successfully.

Questions

1. Is the above understanding and hypothesis correct?
2. 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

[Christine_Li]

Hi, @hyama 

Thanks for creating case to us.

Before answer your questions, can you please help to check whether the NBU version is matched with your SDK version?

If you are not sure, please help to update the NBU which located in your SDK directory:mcuxsdk\middleware\wireless\ble_controller\bin\kw47_nbu_ble_hosted.bin

About how to flash nbu, you can refer to below:

(1) Methods to update NBU firmware on KW47 and MCX W72 - NXP Community

After upgrade the NBU to the same version with SDK, then have a try.

BR,

Christine.

[hyama]

Hi @Christine_Li ,

Thank you for your reply.

We have already programmed the NBU firmware included with SDK version 26.03.00.

However, we have not yet verified whether the NBU firmware was written correctly or whether the currently running NBU firmware version actually matches the SDK version.

Is there a way to check the version of the NBU firmware currently programmed on the device?

If there is a recommended method to verify the NBU firmware version, please let us know.

Best regards,

hyama

[Christine_Li]

Hi, @hyama 

Usually we think the NBU update successfully if you follow the link I provided to you and it returns successful. To double confirm, we provide this API: int PLATFORM_GetNbuInfo(NbuInfo_t *nbu_info_p); to get the NBU info.

To move forward your initial issue, I still wants to know below info:

1.Do you have our KW47-EVK or KW47-LOC board, if you have, can you please have a try with our EVK or LOC board to see whether have same issue on our boards?

2. Did you use our default example in SDK release? Or you have modifies anything based on our example code?

3. If do not use HW reset, but with software reset in IAR, still can reproduce this issue or not?

BR,

Christine.

[Christine_Li]

Hi, @hyama 

How is it now on your side?

Did you get any chance to try with my recommendations?

BR,

Christine.

[hyama]

Hi @Christine_Li 
Apologies for the delay. I haven't had a chance to try it yet, and I'm planning to work on it starting next week.

BR,

hyama.