Debug won't restart

[jmxxx]

I have the FRDM-K64F board, and have been able to successfully build and run the Hello World demo on it. I've also been able to modify the code, and recompile it, but every time I terminate the debug session I am unable to restart it again without disconnecting the board and reconnecting it again. This is quite inconvenient!

I get a console message like this:

MCUXpresso RedlinkMulti Driver v10.0 (Mar 21 2017 01:34:42 - crt_emu_cm_redlink build 190)
Reconnected to existing redlink server (PID 4294967295)
Connecting to probe 1 core 0 (server PID unknown) gave 'Ee(36). Could not connect to core.'
Connecting to probe 1 core 0 (server PID unknown) gave 'Ee(36). Could not connect to core.'
Connecting to probe 1 core 0 (server PID unknown) gave 'Ee(36). Could not connect to core.'
Server OK but no connection to probe 1 core 0 (after 3 attempts) - Ee(36). Could not connect to core.
Failed on connect: Ee(36). Could not connect to core.
No connection to debug probe

I presume this isn't the way things are supposed to work? What am I doing wrong?

Thanks,
John

[rjm]

Yesterday I had the same problem with no restart of a debug session. I had to unplug and plug the USB connection in order to restart a new debug session.

Meanwile, the problem has been solved with a rev254 firmware. But before I got this, I "landed" on this page: https://www.nxp.com/design/software/development-software/sensor-toolbox-sensor-development-ecosystem...

Here, the rev.244 is offered. An old version! This does not operate with current Eclipse 11.x. Please, please (@anthony_huereca) update this page or forward the visitor to this page: https://daplink.io/?board=FRDM-K64F - which results in rev.254.

The fact that I had restart problems shows that the version upon K64F kit delivery (two weeks ago, direclty from NXP) should be before rev.254.

[luisfernandogue]

Hello,

I had the same problem and tryed to install two bootloaders from NXP website:
0244_k20dx_bootloader_update_0x8000.bin
0244_k20dx_bl_0x5000.bin

Both did not work for me. The board was not detected after reconecting the USB cable
Another option is to install the OpenSDAV2 bootlader from Segger.

I followed the isntructions in this link: 

   Segger J-Link Firmware for OpenSDAv2 | MCU on Eclipse 
It worked fine, now I can restart the debug session several times.

[kofikofi]

I have changed the firmware from 0243_k20dx_frdmk64f_0x5000   --->>>>   0226_k20dx128_k64f_0x5000

And I still have the same issue....any fix yet ?  The issue is not with the board, as I have tried the unit on a different machine and it works...it must be a machine issue...any idea what settings to change ? 

MCUXpresso RedlinkMulti Driver v10.0 (Mar 21 2017 01:34:42 - crt_emu_cm_redlink build 190)
Reconnected to existing redlink server (PID 4294967295)
Connecting to probe 1 core 0 (server PID unknown) gave 'Ee(36). Could not connect to core.'
Connecting to probe 1 core 0 (server PID unknown) gave 'Ee(36). Could not connect to core.'
Connecting to probe 1 core 0 (server PID unknown) gave 'Ee(36). Could not connect to core.'
Server OK but no connection to probe 1 core 0 (after 3 attempts) - Ee(36). Could not connect to core.
Failed on connect: Ee(36). Could not connect to core.
No connection to debug probe

[lpcxpresso_supp]

HI,

To help resolve this we need to take a step back and review what we know, so with that in mind I have put some questions below to help us better understand your situation.

1 - Do you know the history of the FRDM-K64 board you are using i.e. is it fresh out of the box, is it known to work, does it display any LEDs when powered?

2 - Please tell us how you have connected to this board, i.e. via the USB connection marked OpenSDA (this is the upper USB port looking at the board with the ports on the left.  Alternatively are you connected using an external debug probe?

Reboot your machine - this is just to give us a known starting state and allow us to rule out more esoteric possibilities

3 - With your board connected and ready to debug, please attach a snapshot from Windows -> Devices and Printers... to show how Windows sees the USB connections.

4 - Start up MCUXpresso IDE and perform a debug operation, then capture the debug log and paste it to this thread. You can capture this from the Console -> Display Selected Console -> <project> Debug Messages

Currently, the initial error you have reported is what you might see if there was no connection between the debug probe and the MCU or the MCU was not powered.

Yours,

MCUXpresso IDE Support

[shellrie]

Unfortunately (but ends in a fortunate situation) I ran into an issue with the freedom board yesterday where the board was no longer being recognized by my windows machine when I plugged it into USB.  I did some digging around and learned that I should try updating the firmware for the board.  I found this webpage (https://developer.mbed.org/teams/NXP/wiki/Firmware-FRDM-K64F) and downloaded the '0226_k20dx128_k64f_0x5000.bin' file that they have a link to on that web page.

I followed the instructions to update the firmware by unplugging the USB cable, pressing and holding the reset button down on the freedom board while also plugging the USB cable back into the computer, and having the 'BOOTLOADER' drive show up in 'My Computer'.  I then copied that firmware/bin file into the 'BOOTLOADER' drive, disconnected the USB, then reconnected it.  When I reconnected the board, it started working again.  Now when I debug, I can debug, kill, and restart debugging and it works.  I no longer have to disconnect the USB and reconnect it to get debugging working again.

I don't know what the original firmware was on the freedom board, nor what the original problem was, but it appears the updated firmware fixed the debug issue.

[shellrie]

Hello everybody.  I have also run into the same problem with the FRDM-K64F board.  I'm building and running the tcpecho example demo for the FRDM-K64F.  It builds successfully, and will start and run in debug mode successfully the first time I run it.  The demo program also works as I'm able to putty to the echo server and have it echo back to me.  When I kill it and try to restart again (in debug mode as before), that's when I run into the issue.

I have attached a series of pictures below to help provide some information as to what my system is running.

[JamiePegg]

Hi John,

I have exactly the same issue. Every time i disconnect the debug session, I need to unplug the USB cable mfrom the board and plug it back in again :smileysad:

Cheers, Jamie

[anthony_huereca]

Can you confirm you both have the latest MBed serial driver installed (it needs to be installed while the board is plugged in): https://developer.mbed.org/media/downloads/drivers/mbedWinSerial_16466.exe 

[JamiePegg]

Hi Anthony,

That is the serial driver that I have installed.

Kind regards

Jamie Pegg

Future Electronics

Technical Solutions Manager New Zealand

Mob +64 (0) 21 2299245

Office + 64 3 982 3256

WARNING: Please do not attach any Export Controlled Technical Data, Documents or Drawings (EAR, ITAR, Military, Aerospace and Satellite) when sending, forwarding or replying to this email.

[anthony_huereca]

Hi John,

  That is unexpected behavior and so far I haven't been able to re-create the issue. Can you confirm you're using the default CMSIS-DAP/MBED connection protocol? Does this happen with the default hello_world project, or only after your code modifications? Are you starting the debug session using the Quickpanel Window, and then terminating the debug session each time by clicking on the red square terminate icon? 

-Anthony

[jmxxx]

Hi Anthony,

Yes, I am using all default settings and code at this stage. I just followed the instructions at FRDM-K64F|Freedom Development Platform|Kinetis MCUs|NXP, starting from scratch again. After importing the demo app, I can start debugging, and step through the hello_world code, typing things in via PuTTY and seeing everything I'd expect. Next I stop the debugging session by clicking the Terminate icon, and the Console window says [Closed Telnet Session].

Now if I want to do some more debugging, I click on "Debug 'frdmk64f_demo_apps_hello_world' [Debug]" in the Quickstart Panel again (like the first time), which seems to successfully do an incremental build of the code again, but I can no longer connect to the debug probe. I get a message exactly the same as I posted above. This is totally consistent for me, and the only way I've found to initiate a new debug session is to unplug the board and plug it back in again.

I'm not sure if it's related, but if I try Debug History in the Run menu then I get an error message saying:

'Launching frdmk64f_demo_apps_hello_world Debug'

has encountered a problem.

There is already a running debug session for the launch

configuration 'frdmk64f_demo_apps_hello_world

Debug'.

This happens whether I unplug the board or not. From this point I seem to have to shut down MCUXpresso and restart it. How should I be terminating the debug session to prevent this problem?

Thanks,

John

[anthony_huereca]

Hi John, 

  You're doing it correctly, so I'm not sure why it's not working for you. I'm checking with our product team to see what could be causing something like this. 

  Could you also try uninstalling and re-installing MCUXpresso IDE again to see if maybe something went wrong during the installation process? Also what OS are you using? 

-Anthony 

[jmxxx]

Hi Anthony,

OK, I guess I could reinstall. I'm using Windows 7 Enterprise, 64-bit, with Service Pack 1.

Regards,

John

[anthony_huereca]

Hi John,

  Some other things to try:

• Look at Section 14.8.7 Troubleshooting LPC-Link2 in the C:\NXP\MCUXpressoIDE_10.0.0_344\MCUXpresso_IDE_User_Guide.pdf document and try killing the processes listed there (most of the LPC-Link2 material also applies to CMSIS-DAP). 
• Try updating the FRDM-K64F OpenSDA firmware to the latest CMSIS-DAP rev0242 OpenSDA Serial and Debug Adapter|NXP 

If it still happens, can you send over the debug messages and gdb messages console logs? 

-Anthony 

[jmxxx]

Hi Anthony,

• Reinstalling MCUXpresso didn't make any difference.
• None of the processes mentioned in 14.8.7 remain running after I terminate the debugger.
• I'm not having any success updating the OpenSDA firmware so far. I can get the board into bootloader mode, but dragging and dropping new firmware to it doesn't seem to work properly. The "drive" disappears from the list in Windows Explorer, but reconnecting the USB cable doesn't do anything. I think I'm even worse off now than I was before!

Regards,

John

[anthony_huereca]

It appears that the binary on that page is for a different bootloader offset than what is on the FRDM-K64F board, and that is why nothing was coming up. Try this binary instead and see if that solves the issue: https://developer.mbed.org/media/uploads/sam_grove/0226_k20dx128_k64f_0x5000.bin