Error: Probe not connected

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Error: Probe not connected

Jump to solution
7,292 Views
fuzy
Contributor II
The FRDM-KW36 board was connected to a PC with a USB cable, and it was confirmed that the debugger can be connected from the MCU Xpresso IDE using the hrs example included in the SDK.
However, when I tried to connect to the debugger the next day, an error occurred and I could not connect.
Since the console log and USB connection are recognized as a USB device, we believe that there is a problem with the connection between OpenSDA and the target.
Can you tell me how to deal with it or what you need to check?
Console log:
----
MCUXpresso IDE RedlinkMulti Driver v11.1 (Dec  4 2019 18:54:35 - crt_emu_cm_redlink build 5)
Found chip XML file in C:/?/frdmkw36_wireless_examples_bluetooth_hrs_freertos/Debug\MKW36Z512xxx4.xml
Reconnected to existing LinkServer process.
Connecting to probe 1 core 0 (using server started externally) reports:
Ee(42). Could not connect to core.'
Retrying...
Reconnected to existing LinkServer process.
Server OK but no connection to probe 1 core 0 (after 3 attempts) - Ee(42). Could not connect to core.
============= SCRIPT: kinetisconnect.scp =============
Kinetis Connect Script
Connecting to Probe Index = 1
Error: Probe not connected
Error: Wire Ack Fault - target connected?
Assert NRESET
Reset pin state: 00
Error: Wire not connected
Power up Debug
Error: Wire not connected
Error: Wire not connected
No Debug Power
============= END SCRIPT =============================
Failed on connect: Ee(42). Could not connect to core.
No connection to chip's debug port
----
So far, I've tried the following, but none of the results have changed:
・Change USB cable
・Change USB port: Confirm both USB2.0 and 3.0
・PC change
Tags (2)
0 Kudos
Reply
1 Solution
7,060 Views
Sebastian_Del_Rio
NXP Employee
NXP Employee

Hi Akihito,

 

The error is happening because the Heart Rate Sensor (hrs) SDK example makes use of the Low-Power mode for the device, causing it to go to a determined power mode, and to disable the required pins and systems to enable debugging.

 

To prevent this, and for a better experience while debugging your MCU, Low-Power mode can be disabled by changing the following macro definition to a "0":

 

/* Enable/Disable PowerDown functionality in PwrLib */
#define cPWR_UsePowerDownMode           0

 

This will disable Power Down functionality for the demo application. This is recommended during debugging, but it can be enabled again for later steps of development.

 

Please let me know if you need any more information.

 

Best regards,

Sebastian

View solution in original post

9 Replies
7,063 Views
Sebastian_Del_Rio
NXP Employee
NXP Employee

Hi Akihito, I hope you're doing well!

 

If the example programmed implemented Low Power mode, it's possible that the device is stuck in low power mode and needs to be woken up to be programmed.

 

Could you please try issuing an "unlock kinetis" command through the J-Link Commander software?:

 pastedImage_1.png

Please let me know if you continue to have issues with your board.

 

Best regards,

Sebastian

2,620 Views
salih
Contributor I

Hello @Sebastian_Del_Rio

I am also working with the FRDM-KW38 Board and I have the same problem. My board is in Low Power mode and I am not able to flash any other application onto it. I cannot connect to the device via J-Link Commander, so I am also not able to issue a  "unlock kinetis" command. How can I flash another Application onto my board? Thanks in advance!

0 Kudos
Reply
6,464 Views
erickr
Contributor I

Hello. I'm having the same problem. I uploaded the bluetooth_hrs_freertos example and now I'm not able to debug it again to upload a different code to the KW36 FRDM board. I cannot access also JLINK Commander since it cannot detect the USB Probe. I'm stuck. Please help on how to upload new code to the board. 

erickr_1-1624954022458.png

 

erickr_0-1624953582112.png

 

6,440 Views
CarlosFG
Contributor II

I have the same problem here with the twr-km35z512VL. I was messing with the linker script and, after a flash, the JLinkExe detects the probe no more. It says: "No emulators connected via USB" even "lsusb" shows me the device "ID 0d28:0204 NXP ARM mbed".

In case someone found these useful:

The header of the last ihex binary flashed:

 

 

:1000000000C0002085020000E9020000ED020000AF
:1000100000000000000000000000000000000000E0
:10002000000000000000000000000000F1020000DD
:100030000000000000000000F5020000BD0E0000FE
:10004000FD02000001030000050300000903000099
:100050000D030000E5020000E5020000E5020000DB
:10006000E5020000E5020000E5020000E5020000F4
:10007000E5020000E5020000E5020000E5020000E4
:10008000E5020000E5020000E502000011030000A7
:10009000E5020000E5020000E5020000E5020000C4

 

 

The memory map used:

 

 

Name             Origin             Length             Attributes
m_interrupts     0x0000000000000000 0x0000000000000200 xr
m_flash_config   0x0000000000000200 0x0000000000000010 xr
m_text           0x0000000000000210 0x0000000000032000 xr
m_sram           0x000000001fffc000 0x0000000000010000 rw
*default*        0x0000000000000000 0xffffffffffffffff

 

 

EDITED:

I've been trying to update OpenSDA Bootloader following this instrucction with no success: https://www.nxp.com/design/software/development-software/sensor-toolbox-sensor-development-ecosystem...

EDITED 2:

If I create a file named "assert.act" into the MSD root folder, the bootloader responds with an ASSERT.TXT (see msd commands doc

Assert
File: (file)
Line: 151
Source: Bootloader

 The file DETAILS.TXT contains the following:

# DAPLink Firmware - see https://mbed.com/daplink
Unique ID: 0000000048824e45002f7008dd8900378761000097969900
HIC ID: 97969900
Auto Reset: 0
Automation allowed: 1
Overflow detection: 0
Daplink Mode: Bootloader
Bootloader Version: 0243
Git SHA: 2f498feb503c4396822ef00f6fbf8c5289dfa9c0
Local Mods: 1
USB Interfaces: MSD
Bootloader CRC: 0xf95f84e6
Interface CRC: 0x308c203a
Remount count: 0

 

EDITED 3:

I finally solved it reflashing both micros with an external JTAG (JLink EDU). I used the "k20dx_twrkm35z75m_if_crc_combined.bin" binary for the K20 (you can found it in here) and a working "blinking.hex" for the KM35.

0 Kudos
Reply
6,629 Views
shengds
Contributor I

Hi Sebastian,

    I am using FRDM-KW38, and get same problem. But how can I use COMSIS-DAP to unlock the demo board? As you know, If I use Jlink, I need open OpenSDA wire on the board.  You can see this point in schmatic of FRDM-KW38.

   Is there any other solution? I have try to download other project file, but fail.

 

shengds_0-1620223481698.png

 

0 Kudos
Reply
7,063 Views
fuzy
Contributor II

Hi, Sebastian

I've confirmed that the problem can be solved in the way you taught, but it always seems to recur when disconnect the debugger.
I unlock every time. Is there a workaround?
The debug target is the hrs example based software included in the SDK.

0 Kudos
Reply
7,061 Views
Sebastian_Del_Rio
NXP Employee
NXP Employee

Hi Akihito,

 

The error is happening because the Heart Rate Sensor (hrs) SDK example makes use of the Low-Power mode for the device, causing it to go to a determined power mode, and to disable the required pins and systems to enable debugging.

 

To prevent this, and for a better experience while debugging your MCU, Low-Power mode can be disabled by changing the following macro definition to a "0":

 

/* Enable/Disable PowerDown functionality in PwrLib */
#define cPWR_UsePowerDownMode           0

 

This will disable Power Down functionality for the demo application. This is recommended during debugging, but it can be enabled again for later steps of development.

 

Please let me know if you need any more information.

 

Best regards,

Sebastian

2,133 Views
Prentim2
Contributor I

Hello,

 

I seem to be having the same issue and can't seem to find this define: 

/* Enable/Disable PowerDown functionality in PwrLib */
#define cPWR_UsePowerDownMode           0‍‍

within the PWRLib.c and PWRLib.h files. Do you know where I might be able to find this #define?

0 Kudos
Reply
7,063 Views
fuzy
Contributor II

Hi, Sebastian

The problem was solved in the way you taught. Thanks for your advice!

0 Kudos
Reply