Issue Debugging OpenThread Images on JN5189DK6 with J-Link – "No source available for main()"

[Vvg1997]

Dear NXP Support Team,

I am currently working with the JN5189DK6 development kit and attempting to flash and debug an OpenThread RCP image ( ot-rcp.elf) built from the OpenThread stack. I am encountering an issue where the debugger is unable to resolve symbols, specifically showing:

• No source available for "main() at 0x5da"

Configuration Details:

• Target MCU: JN5189DK6
• SDK Used: SDK_2_6_16_JN5189DK6
• OpenThread Version/Reference: Based on instructions from ot-nxp v1.4.0 README
• Debugger: Segger J-Link (SWD interface)
• Debugging Interface: Not using CMSIS-DAP (as mentioned in NXP guide)
• Flashing Format: .hex and .elf
• Debugging File: ot-cli-ftd.elf
• IDE Version : MCUXpressoIDE_24.12.148

Steps Taken:

1. Built the OpenThread RCP firmware for the JN5189 target with debug symbols enabled.

2. Connected the Segger J-Link debugger to the board using the SWD interface.

3. Loaded the ot-rcp.elf into the debugger for symbol reference.

4. Started a debug session, but encountered the message:

   • No source available for "main() at 0x5da"

Attachments:

• Board configuration images

• Debugging file (ot-rcp.elf)

• Project configuration screenshots

[mihai_ignat · Accepted solution]

Hello.

The issue you are seeing is due to the fact that the build is done using "MinSizeRel" option which strips the debug symbols.

To fix this, you need to change the following line: https://github.com/NXP/ot-nxp/blob/release/v1.4.0/script/build_jn5189#L40

from "MinSizeRel" to "RelWithDebInfo", rebuild the image and flash. Can you please try this change and provide your feedback?

Have a good day!

Mihai

[Vvg1997]

HI Mihai,

Thank you for providing a solution regarding the RCP debugging setup through the MCU IDE.

As a follow-up, I need help with one more point:
When connecting the NXP board to my laptop with the RCP firmware, is it possible to view the logs of the RCP directly through the MCU IDE? If so, could you please guide me on how to access them or configure the IDE to enable this?

[mihai_ignat]

Hello.

Logging for any ot-nxp app on JN5189 can be enabled by modifying some of the defines from the build. From my memory, as I worked on this some time ago, you need to modify:

- OPENTHREAD_CONFIG_LOG_OUTPUT to OPENTHREAD_CONFIG_LOG_OUTPUT_PLATFORM_DEFINED in src/k32w0/jn5189/openthread-core-jn5189-config.h

- OPENTHREAD_CONFIG_LOG_LEVEL to OT_LOG_LEVEL_DEBG in the same file

- UART_USE_SWO_LOG to 1 in src/k32w0/jn5189/jn5189-sdk-config.h

- UART_USE_DRIVER_LOG and UART_USE_SERIAL_MGR_LOG to 0 in the same file as above

This should enable logging on the SWO interface, which by default routes to pin 14 on P10 header and it also routes to the external LPC-Link2 SWO_TRGT. With that set, you should be able to see the logs by either probing the pin 14 with an external FTDI to USB adapter (connect pin to the RX pin of the FTDI adapter) or in MCUXpresso ITM viewer. An app note on that is available here: https://community.nxp.com/pwmxy87654/attachments/pwmxy87654/mcuxpresso%40tkb/41/1/How%20To%20Use%20S...

I need to retest this on my side to confirm, and I will try to do this in the following days, but for now, you should have some information to get started on your side.

BR,

Mihai

[Vvg1997]

Hi Mihai,

I've followed the above-mentioned steps, and I'm able to successfully direct the logs to IDE.

Thanks for your assistance.

BR
Vikash

[Vvg1997]

Hi Mihai,

I’m running into a repeatable “rcp out” error whenever I debug through the LPC-Link2 onboard probe in MCUXpresso IDE—even when I launch the session with no breakpoints set.

If I switch to an FTDI-USB connection, with the previously flashed binary, there is no issue of time-out at all.

Regards
Vikash

[mihai_ignat]

Hello, Vikash.

You are seeing RCP timeouts on the host side, meaning the MPU/MCU host running ot-daemon, which is normal, because while you are debugging the JN5189 RCP application, you are stopping the code execution on the chip and implicitly, the UART communication to the host.

Using the FTDI USB doesn't stop the processor and communication, so it is normal to not see such events.

BR,

Mihai

[Vvg1997]

Hi Mihai,

I’ve tried running the application with a free run configuration and made sure that no breakpoints are set, but I’m still encountering the same issue while checking through the LPCLINK2 port.

Specifically, on the RCP side, we’re observing that bytes are being dropped or missed when the OTBR is transmitting high-volume(100-150 Bytes) messages in quick succession. This seems to indicate a potential issue with handling high RX load or buffer overflows(at present Rx buffer value is 10kb).

Please let me know if there are any additional settings or steps I should verify, or if there’s something else that might be causing this behavior.

BR,
Vikash

[mihai_ignat]

Hello, Vikash.

What I can suggest is to have a look at K32W0 configuration for flow control. More specifically, in script/build_k32w061, there is a build option:

OT_OPTIONS_RCP_ONLY_UART_FLOW_CONTROL=(
    "-DOT_RCP_FLOW_CONTROL=ON"
    "-DOT_APP_CLI=OFF"
    "-DOT_FTD=OFF"
    "-DOT_MTD=OFF"
    "-DUART_BAUD_RATE=1000000"
)

This sets to ON the OT_RCP_FLOW_CONTROL option, which enables the SDK option 

gUartHwFlowControl_d

Looking into the SDK in boards/<chip>/wireless_examples/openthread/reed/bm/board.c, you can see that this enables RTS and CTS pin usage for flow control on UART0, by default on PIO6 for RTS and PIO7 for CTS. You can adjust the pins to other USART0 used pins by referencing Table 3 in JN5189 User Manual .

This should improve the stability of the UART communication.

K32W0x1 is pin compatible with JN5189, it's actually the JN5189 variant with BLE, so you can take as reference the K32W0 SDK.

BR,

Mihai

[Vvg1997]

Hi Mihai,

Thanks for your suggestion. Unfortunately, the end platform where I’ll be integrating the JN5189 doesn’t support hardware flow control, so I’ll need to explore alternatives that work without it.

One follow-up question:-
1) is it possible to enable and redirect the debug logs by configuring a GPIO as a different USART instance and then view the output using Minicom?

Best Regards,
Vikash

[mihai_ignat]

Hello, Vikash.

The debug logs are printed on the USART1 instance. You can check the JN5189 User Manual , table 3 about what other pins can be used for USART1. JN5189 has two USART instance, with USART0 for the OpenThread CLI/Spinel communication.

On a quick search, we have:

USART0_TXD: PIO3, PIO8, PIO18.

UASRT0_RXD: PIO2, PIO9, PIO19.

USART1_TXD: PIO0, PIO6, PIO10, PIO20.

UASRT1_RXD: PIO1, PIO7, PIO11, PIO19.

BR,

Mihai

[Vvg1997]

Hi Mihai,

I’m currently facing several issues while setting up UART communication and debug logging for the JN5189 in my OpenThread Border Router (OTBR) environment. I’ve detailed the points below:

1) When I use the LPC-LINK2 port (even without the debugger, solely for UART communication), I encounter HDLC parse errors or framing errors shortly after launching the otbr-agent. In contrast, using the FTDI-USB UART interface works reliably, and the agent maintains communication unless exposed to heavy command loads. 

I have attached the jumper setting when using the LPC-LINK2 port. (Refer to the attached image : Jn5189_Debug_port_jumper_config_.png)

2) I attempted to enable debug logs via USART1 (TX/RX on pins 10/11), considering the compatibility between K32W0 and JN5189. However, when I connect a USB-UART adapter and monitor the output via Minicom, no logs are displayed. Also, the otbr-agent fails to receive messages and eventually times out.

Here’s what I’ve modified so far:

In jn5189-sdk-config.h:

#define UART_USE_DRIVER 1

#define UART_USE_SERIAL_MGR 0

#define UART_USE_DRIVER_LOG 1

#define UART_USE_SERIAL_MGR_LOG 0

#define UART_USE_SWO_LOG 0

Added the following to the CMake config:

option(OT_DEBUG_CONSOLE_ENABLE "Enable debug console on gOtLogUartInstance" ON)

if (OT_DEBUG_CONSOLE_ENABLE)

target_compile_definitions(${NXP_DRIVER_LIB}

PUBLIC

-DgUartDebugConsole_d=1

)

endif()

In the build_jn5189 script, under OT_OPTIONS, I added:

-DOT_DEBUG_CONSOLE_ENABLE=ON

Despite these changes, no output is observed on USART1, and OTBR communication fails.

3) Is it possible to capture SWO debug logs using Minicom or similar terminal applications? If not, what tool or method is recommended for viewing SWO output on JN5189?

4) While creating the project and setting the RAM regions via:

-> Project → Properties → C/C++ Build → MCU Settings → JN5189 → Apply & Close

-> I noticed a mismatch between the RAM boundary values shown in the IDE and those defined in the linker script.

In the IDE: (Refer to the attached image :JN5189_Mem_Layou_Ide.png)

RAM0: 0x4000000, Size: 0x15FE0

RAM1: 0x4020000, Size: 0x10000

In the jn5189 linker script (src/k32w0/jn5189/jn5189.ld) :

RAM0: 0x4000400, Size: 0x0015C00

RAM1: 0x4020000, Size: 0x10000

Which of these memory configurations should be considered correct? Should we align the IDE settings with the linker script, or vice versa?

BR,

Vikash

  

[mihai_ignat]

Hello, Vikash.

Regarding 1), the difference between routing the UART between LPC-Link2 port and the FTDI port is that on the FTDI port, the UART is routed to the FT230XS FTDI chip on the DK6 board, which translates the signals to USB on a more "hardware" logic, implying that it's done faster. On the LPC-Link2 port, the signals are passed through the LPC4322 chip, which acts also as a debugger probe and I suspect that it implies a more "software" approach, with more processing leading to some delays.

We haven't seen any issues using that port on our scenarios, but we do suggest using the FTDI port for real life scenarios, due to the limitations which I pointed out. One thing I can suggest to you is to switch the firmware running on the LPC Link2 chip. You can do this by putting the LPC in DFU mode (switch JP5 from NORMAL to DFU) and use the LPCScrypt software to do the change. A user guide is available in the link. You have the option to use the CMSIS or the JLink firmwares.

Regarding 2), I suggest using UART_USE_SERIAL_MGR instead of UART_USE_DRIVER. The changes I suggested in the post earlier should also be done:

- OPENTHREAD_CONFIG_LOG_OUTPUT to OPENTHREAD_CONFIG_LOG_OUTPUT_PLATFORM_DEFINED in src/k32w0/jn5189/openthread-core-jn5189-config.h

- OPENTHREAD_CONFIG_LOG_LEVEL to OT_LOG_LEVEL_DEBG in the same file

Regarding 3), yes, I remember capturing SWO debug lines in TeraTerm so it should work.

Regarding 4), the change in linker file, RAM0: 0x4000400 was done to accommodate RAM needs from running the ROM code at boot (scratch RAM) and you can also change the settings in MCUXpresso to match, but I don't think it has any impact if you keep the old settings, as we are not loading any applications in RAM when writing the board.

JN5189 is a legacy part and some things are out of date and won't be updated in next releases. Furthermore, JN5189 and K32W0x1 are to be removed from ot-nxp repository in next releases and enter a maintenance phase on the last released version.

If you desire to develop a solution with NXP OpenThread Wireless silicon that will benefit from ongoing support regarding stack and SDK maintenance, I can suggest you to have a look at the MCXW7x family.

BR,

Mihai

[Vvg1997]

Hi Mihai,

1) We are constrained to the JN5189 since we already have a significant number of devices deployed with this hardware.

2) I’ve tried using a baud rate of "1000000," but I’m still encountering a framing error during communication.

I’ve tested with both UART_DRIVER and SERIAL_MGR. Why is SERIAL_MGR preferred?

To debug further, I enabled logs and checked the USART FIFO Overflow Register values. I noticed that the RXERR bit is being set in FIFOSTAT.

For reference, USART0 is clocked at 32 MHz (sourced from XTAL), and the main clock is running at 48 MHz.

BR,
Vikash

[mihai_ignat]

Hello, Vikash.

After consulting with R&D, I think I can offer a better solution.

As I said, JN5189 and K32W0x1 are compatible chips from the same family, the K32W0x1 being the upper trim of JN, with BLE added. In the K32W0x1 ot-nxp examples, there is a rcp_only_uart_dma configuration that is recommended to be used in your actual use case, RCP without frame control. You can check it out in script/build_k32w061.

OT_OPTIONS_RCP_ONLY_UART_DMA=(
    "-DOT_RCP_UART_DMA=ON"
    "-DOT_APP_CLI=OFF"
    "-DOT_FTD=OFF"
    "-DOT_MTD=OFF"
    "-DOT_1_2_SUPPORT=ON"
    "-DUART_BAUD_RATE=1000000"
)
readonly OT_OPTIONS_RCP_ONLY_UART_DMA

This example uses a special DMA library which improves the UART and radio modules handling.

You can build the K32W0 example and use it on JN5189 for your testing.

BR,

Mihai

[Vvg1997]

Hello Mihai,

Thank you for your patience and the time you spent addressing each of the four points I raised.

Your clear explanations have given me clarity and helped me understand the issues better.

BR,
Vikash

[Vvg1997]

Hello,

Thanks for your prompt reply.

I'll follow the above specified steps and get back to you.