Actions
Forum Thread Details
  • State Verified Answer
  • Replies 8 replies
  • Subscribers 40 subscribers
  • Views 375 views
  • Users 0 members are here
Related

NO connection to chips debug port on the MCXN236?

skruglewicz

I’m still having problems with the MCXN236 . Can't find the probe 

CONSOLE log:

LinkServer RedlinkMulti Driver v25.6 (Jun 26 2025 19:34:05 - crt_emu_cm_redlink build 1017)
Found chip XML file in C:/nxp/workspace/frdmmcxn236_hello_world/Debug\MCXN236.xml
( 5) Remote configuration complete
Reconnected to the existing LinkServer process.
Connecting to probe 2 core 0 (using server started externally) reports:
'Ee(42). Could not connect to core.'
Retrying...
Reconnected to the existing LinkServer process.
Server OK but no connection to probe 2 core 0 (after 3 attempts) - Ee(42). Could not connect to core.
Failed on connect: Ee(42). Could not connect to core.
No connection to chip's debug port

image

 I'm dead in the water with the MCXN236 and can not develop my project without it Does any one know why thus is happening? Is my board defective? 

any help here would be appreciated.

Thanks 

Steve K

Parents
  • 0

    UPDATE STATUS on this problem

    It works on the new PC with a clean MCUXpresso + SDK install, so the board and probe are fine, and the root cause is almost certainly something broken or conflicting on the original PC’s toolchain/driver side rather than the hardware.

    Brief summary

    On a new PC I installed MCUXpresso (24.12) and the SDK (24.12.00), connected the FRDM‑MCXN236, built an example, and debug worked immediately. On the original PC I have MCUXpresso 25.6 with SDK 25.09.00, and despite reinstalling, updating LinkServer, trying LinkFlash, firmware updates, and ISP/bootloader mode, you still get Ee(42). Could not connect to core / No connection to chip's debug port.That confirms the FRDM‑MCXN236 and MCU‑Link firmware are good and isolates the problem to the original  Windows environment.

    Likely causes on the original  PC

    Most probable categories, given that the exact same board works elsewhere:

    • Corrupted or conflicting USB/debug drivers (MCU‑Link / CMSIS‑DAP / WinUSB) on the   original  PC, possibly from prior NXP, SEGGER, PE Micro, or other probe installs.

    • A stale or mismatched LinkServer instance or config on the   original  PC that the IDE keeps reusing, so the probe enumerates but SWD never actually connects to the target core.

    • Security/IT software (AV, endpoint protection, USB control) on the   original  PC interfering with USB enumeration or blocking the debug interface, while the new laptop is more “clean.

    • Leftover MCUXpresso or SDK fragments from original versions in different paths, causing the IDE to point at the wrong debug driver or XML/config for MCXN236 even though the latest SDK is installed.

    I have researched a few things I could try which I will and update this post. so stay tuned

Reply
  • 0

    UPDATE STATUS on this problem

    It works on the new PC with a clean MCUXpresso + SDK install, so the board and probe are fine, and the root cause is almost certainly something broken or conflicting on the original PC’s toolchain/driver side rather than the hardware.

    Brief summary

    On a new PC I installed MCUXpresso (24.12) and the SDK (24.12.00), connected the FRDM‑MCXN236, built an example, and debug worked immediately. On the original PC I have MCUXpresso 25.6 with SDK 25.09.00, and despite reinstalling, updating LinkServer, trying LinkFlash, firmware updates, and ISP/bootloader mode, you still get Ee(42). Could not connect to core / No connection to chip's debug port.That confirms the FRDM‑MCXN236 and MCU‑Link firmware are good and isolates the problem to the original  Windows environment.

    Likely causes on the original  PC

    Most probable categories, given that the exact same board works elsewhere:

    • Corrupted or conflicting USB/debug drivers (MCU‑Link / CMSIS‑DAP / WinUSB) on the   original  PC, possibly from prior NXP, SEGGER, PE Micro, or other probe installs.

    • A stale or mismatched LinkServer instance or config on the   original  PC that the IDE keeps reusing, so the probe enumerates but SWD never actually connects to the target core.

    • Security/IT software (AV, endpoint protection, USB control) on the   original  PC interfering with USB enumeration or blocking the debug interface, while the new laptop is more “clean.

    • Leftover MCUXpresso or SDK fragments from original versions in different paths, causing the IDE to point at the wrong debug driver or XML/config for MCXN236 even though the latest SDK is installed.

    I have researched a few things I could try which I will and update this post. so stay tuned

Children
No Data