"update RPM packages proposal list" loops forever on KDS release version 1.1.0

[johnbaker]

When trying to debug using OPENSDA usb port I very often get the below error then it loops forever saying at the bottom: "update RPM packages proposal list".

----------------------------------------------------------------------------------------------

P&E GDB Server, Version 5.07.00.00

Copyright 2014, P&E Microcomputer Systems Inc, All rights reserved

Loading library C:\Freescale\KDS_1.1.0\eclipse\plugins\com.pemicro.debug.gdbjtag.pne_1.0.9.201407221237\win32\gdi\unit_ngs_arm_internal.dll ... Done.

Command line arguments: -device=K64FN1M0M12 -startserver -serverport=7224 -interface=OPENSDA -port=USB1 -speed=5000 -USE_CYCLONEPRO_RELAYS=0 -FORCE_MASS_ERASE=0

Device selected is k64fn1m0m12

User Specified Hardware Selection : Interface=OPENSDA and Port=USB1

Connecting to target.

Error opening selected communication interface

Error - Port not found.

Can not enter background mode  .

Terminating Gracefully...

Unable to initialize PEDebug.

PE-ERROR: Failed to Initialize Target

PE-ERROR: EXCEPTION : Could not bind socket. Address and port are already in use.

PE-ERROR: Unable to start server with the settings provided. Halting.

Target Disconnected.

---------------------------------------------------------------------------------------

[BlackNight]

Interesting thing about that RPM thing, glad you found (and shared!) the solution to this!

[BlackNight]

Hi John,

I assume you are using the FRDM-K64F board with the P&E OpenSDA firmware loaded, correct?

are you saying you get that sometimes (or often), but not always? I have not seen something like this. Below is what I get as reference.

Now here is what you might check:

I had once a problem that the gdb server somehow was a zombie (not terminated correctly).

To make sure that there is no zombie process hanging around, go to the task manager and check in the task manager for the two following processes:

- arm-none-eabi-gdb.exe

- pegdbserver_console.exe

Both are running if you are debugging. But they shall not be present if you termiated a debugging session (or if you are not debugging).

Can you check this?

Thanks,

Erich

P&E GDB Server, Version 5.07.00.00

Copyright 2014, P&E Microcomputer Systems Inc, All rights reserved

Loading library C:\Freescale\KDS_1.1.0\eclipse\plugins\com.pemicro.debug.gdbjtag.pne_1.0.9.201407221237\win32\gdi\unit_ngs_arm_internal.dll ... Done.

Command line arguments: -device=K64FN1M0M12 -startserver -serverport=7224 -interface=OPENSDA -port=USB1 -speed=5000 -USE_CYCLONEPRO_RELAYS=0 -FORCE_MASS_ERASE=0

Device selected is k64fn1m0m12

User Specified Hardware Selection : Interface=OPENSDA and Port=USB1

Connecting to target.

OpenSDA detected - Flash Version 1.08

Device is K64FN1M0M12.

Mode is In-Circuit Debug.

'Kinetis' is a registered trademark of Freescale.

(C)opyright 2012, P&E Microcomputer Systems, Inc. (www.pemicro.com)

API version is 101

Server running on 127.0.0.1:7224

Connection from "127.0.0.1" via 127.0.0.1

Copyright 2012 P&E Microcomputer Systems,Inc.

Command Line :C:\Freescale\KDS_1.1.0\eclipse\plugins\com.pemicro.debug.gdbjtag.pne_1.0.9.201407221237\win32\pegdbserver_console -device=K64FN1M0M12 -startserver -serverport=7224 -interface=OPENSDA -port=USB1 -speed=5000 -USE_CYCLONEPRO_RELAYS=0 -FORCE_MA

CMD>RE

Initializing.

Target has been RESET and is active.

CMD>CM C:\Freescale\KDS_1.1.0\eclipse\plugins\com.pemicro.debug.gdbjtag.pne_1.0.9.201407221237\win32\gdi\P&E\k64fn1m0m12_pflash_pipeline.arp

Initializing.

Initialized.

;version 1.01, 11/11/2013, Copyright P&E Microcomputer Systems, www.pemicro.com [mk64_1024k_n_pflash0_pflash1_pipeline]

;device freescale, k64fn1m0m12, 1x32x256k, desc=pflash_pipeline

;begin_cs device=$00000000, length=$00100000, ram=$20000000

Loading programming algorithm ...

Done.

CMD>EM

Erasing.

Module has been erased.

Initializing.

Initialized.

;version 1.01, 11/11/2013, Copyright P&E Microcomputer Systems, www.pemicro.com [mk64_1024k_n_pflash0_pflash1_pipeline]

;device freescale, k64fn1m0m12, 1x32x256k, desc=pflash_pipeline

;begin_cs device=$00000000, length=$00100000, ram=$20000000

Loading programming algorithm ...

Done.

CMD>PM

Programming.

Processing Object File Data ...

.

Programmed.

CMD>VC

Verifying object file CRC-16 to device ranges ...

   block 00000000-00000197 ...

Ok.

   block 00000410-00001A6F ...

Ok.

   Checksum Verification Successful. (Cumulative CRC-16=$35E2)

CMD>RE

Initializing.

Target has been RESET and is active.

Preset breakpoint encountered.

[johnbaker]

I stopped the project debug and the arm-non-eabi-gdb.exe persists in TaskManager. (see attached).  The pegdbserver_console.exe process terminated fine.

[johnbaker]

I started the same project up in DEBUG mode again to see what happens.  I received the same error "No source available for "0x530", but did not get an error on the USB port.  There are two "arm-none-eabi-gdb.exe" processes in Task manager now.  (See attached).  I am assuming the stuck one came from some error in testing earlier in the morning.  I will end task it.

[johnbaker]

Here is a snapshot of my Debug Configurations.  I forgot to reply to one of your earlier questions.  I have both the Freedom board and the Tower board.  I am currently testing with the TWR-K64F120M board.

John

[BlackNight]

Hi John,

that debug configuration looks correct.

In essence, what I think, is that your problem reported at the beginning here was about the zombie (duplicated or stalled) gdb executable.

So I think this part is 'solved'?

Erich

[johnbaker]

Hi Erich,

Thanks for your help. Yes I think this turned out to be two separate issues. I still get the zombie ‘arm-non-eabi-gdb.exe’ processes periodically. I have been just ‘end tasking’ them when it happens for now.

John Baker

[BlackNight]

Hi John,

I'm wondering how you get them. GDB is not very good if I'm debugging (forget to terminate) and then switch to the C/C++ perspective, and then launch again. Usually it will just not allow me to connect (as already debugging), so I try always to stop/terminate the debug session before I go back to compile and then debug again. Could you have an eye on this (always terminate before you start a new debug session), so I know if this could be the cause of your zombie processes?

Erich

[johnbaker]

Snapshot1:

I started KDS, made sure that there were no breakpoints then clicked 'debug'.  KDS set a temporary checkpoint on the 'PE_low_level_init()' routine but did not crash. (or stop at a breakpoint).

Snapshot2:

I clicked the red square button to kill the 'debug'. arm-none-eabi-gdb.exe process went away.

Snapshot3:

I clicked the 'debug' button again and I get the 'No source available' error yet it still looks like it is running.  arm-none-eabi-gdb.exe process is still running.

I hit the red square button to close debug and the arm-none-eabi-gdb.exe went away.

Snapshot4:

I clicked on the 'Debug' button again and got the same results as before except for a different source address on the error.

I hit the red square button to close debug and the arm-none-eabi-gdb.exe went away.  I tried this several times and as long as I clicked the red stop button first the arm-none-eabi-gdb.exe process went away.

Snapshot5:

This time instead of hitting the red stop button I switched perspectives back to the C/C++ view, modified line 52 to read: for(;;){ int l=0;}  then clicked the debug button and received this error.

I kept getting this error until I killed the arm-none-eabi-gdb.exe process with task manager.  Then I got the No Source Available error again.

As long as I stopped debugging by clicking on the red square button first I did not have the issue of the arm-none-eabi-gdb.exe process hanging.

John

[BlackNight]

Hi John,

many thanks for the detailed steps, appreciated. So it confirms that it has something to do with not terminating an already existing debug session.

I would need to dig into this more what could cause this, and if this is a general GDB problem.

Until then, my recommendation is to terminate the debugging session before starting a new one.

Erich

[johnbaker · Accepted solution]

Create an empty file 'C:\Users\your_account\.pkglist'.

Per this link this issue is resolved.  As soon as I created the .pkglist file the looping stopped.

Bug 361862 – "Automatically build the RPM packages proposals list" preference ignored