Disconnection bug?

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

Disconnection bug?

Jump to solution
5,433 Views
quevedo
Contributor V

Hello,

 

I have ran into what seems to be a bug in beta version, and I have not found any answers for that so far. When I am running debugger, if I click on "Disconnect" button, the debugger should disconnect and the program should keep running on target board. However, when I try to disconnect, the program halts. The debugger acts as if I had clicked the "Terminate" button.

 

I have tried that with a blinking LED program, using Processor Expert with a BitIO for the LED and a periodic interrupt timer. When I click on "Disconnect" the program halts. I have tried that with both a FRDM-KL25 board (P&E Multilink OpenSDA interface) or a FRDM-K64F (Segger J-Link interface).

 

Am I doing anything wrong? Or is this a real bug?

 

Cheers,

 

Antonio

Labels (1)
0 Kudos
Reply
1 Solution
2,537 Views
BlackNight
NXP Employee
NXP Employee

Hi Antonio,

if you are using OpenOCD with CMSIS-DAP, then I have a solution for you. Inside the debugger configuration, under 'Other options', use this:

-f kinetis.cfg -c "kinetis.cpu configure -event gdb-detach {

  resume

}"

pastedImage_0.png

Erich

View solution in original post

0 Kudos
Reply
10 Replies
2,537 Views
BlackNight
NXP Employee
NXP Employee

Hi Antonio,

yes, this is a bug, we saw it already in the pre-beta, but somehow got missed for the release notes (is added now).

My understanding the bug is how the GDB server is handling the disconnect command. And it is different depending on which GDB server you are using:

- P&E and OpenOCD: they both stop the target, then they disconnect.

- Segger: it stops the target (but does not disconnect)

Correct would be to disconnect while the target is still running.

I have filed corresponding tickets to P&E, Segger, so hopefully this can be addressed for the V1.1 GA (General Availability) release.

Thanks for reporting!

Erich

0 Kudos
Reply
2,537 Views
davidnemes
Contributor I

I found that this bug still has not been fixed for P&E JTAG, using Kinetis SDK v1.1.0.

0 Kudos
Reply
2,538 Views
BlackNight
NXP Employee
NXP Employee

Hi Antonio,

if you are using OpenOCD with CMSIS-DAP, then I have a solution for you. Inside the debugger configuration, under 'Other options', use this:

-f kinetis.cfg -c "kinetis.cpu configure -event gdb-detach {

  resume

}"

pastedImage_0.png

Erich

0 Kudos
Reply
2,537 Views
quevedo
Contributor V

Hello Erich,

I have tried this option with my FRDM-K64 board, with a blinking LED program. When I tried to debug, I got this message on Console:

Quit (expect signal SIGINT when the program is resumed)

Quit (expect signal SIGINT when the program is resumed)

Exception condition detected on fd 0

error detected on stdin

Quit (expect signal SIGINT when the program is resumed)

What can be going wrong?

Cheers

0 Kudos
Reply
2,537 Views
BlackNight
NXP Employee
NXP Employee

Hi Antonio,

Does it show this?

So yes, I have this too (mostly for the first debug session after starting Eclipse). I'm not sure why. But what helped me so far is then to unplug the board and plug it in again. Can you try this?

Erich

0 Kudos
Reply
2,537 Views
tharonhall
Contributor IV

I am seeing similar issues with my K22F board. At work, a lot of issues were corrected by the debug setting recommendation that Erich gave, for which I am thankful. :smileyhappy:

It's crunch time and I am now trying to work from home using my own laptop. I am using the same project from work (checked out via SVN) and the same board. However, I can't connect to the K22F at all, including when I restart the Eclipse and re-power the board, or even if I re-power after starting KDS. I get the exact same error. I did confirm that he debug settings look correct.

I did create a new workspace for my home laptop, as workspaces do not look to be very portable.

As I REALLY need to get some work done this weekend, any advise is appreciated. :smileyhappy:

0 Kudos
Reply
2,537 Views
marcotiberio
Contributor I

Dear Erich and Antonio,

I have almost the same problem debugging my FRDM-K64F with OpenOCD.

The debugger won' t start and to the console I have the same messagge:

Quit (expect signal SIGINT when the program is resumed)

Exception condition detected on fd 0

error detected on stdin


I have already debugged many many times before, but all at once I am no longer able to debug my projects, even those who work before...

I have already tried your solutions but it has not solved my problem.

Thanks in avance for your replies.

Best regards.

0 Kudos
Reply
2,537 Views
BlackNight
NXP Employee
NXP Employee

Which mbed/CMSIS-DAP firmware are you using on the FRDM-K64F? The latest (0203) from Firmware FRDM K64F - Handbook | mbed?

0 Kudos
Reply
2,537 Views
BlackNight
NXP Employee
NXP Employee

On another thought: is the red reset LED on (or nearly always on)?

You might try to load the attached .bin file with the mbed bootloader to recover the device.

Additional recovery methods are described in http://mcuoneclipse.com/2014/04/19/recovering-frdm-k64f-mbed-board/

I hope this helps,

Erich

2,537 Views
marcotiberio
Contributor I

Hi Erich,

thank you for responding so quickly.

Yeah! I have loaded the .bin file and I have recovered the board. Now I am able again to debug my projects!

Thank you very much.

Best regards.

Marco

0 Kudos
Reply