Is there an explanation for the following debugger behavior??

mjbcswitzerland · ‎12-13-2016

Hi All

In KDS 3.2.0 I have the following debug behavior (it was OK with the previous version as far as I can remember). The behavior is the same for various debuggers (P&E adapter, OpenSDA etc). The same on all Kinetis processors tried with

1. Downloading it stops at main() as expected
2. Stepping code works
3. Setting breakpoints and running between then works
4. BUT running causes the debugger no no longer offer the PAUSE. Sometimes it is possible to get to reset and return to main() by clicking on the RESET/restart symbol but often it doesn't react to this.
When the debugger "runs away" like this it is necessary to disconnect and start again.
The code otherwise works normally.

There may be a hint; when downloading code there is a warning that there is no reset script defined (or similar).

Any ideas why KDS debugger is playing up like this - with IAR, Keil etc. the same project debugs normally....

Regards

Mark

ZhangJennie · ‎12-14-2016

Hi.

1. do you mean message:

"

WARNING - NO RESET SCRIPT FILE HAS BEEN CONFIGURED TO RUN!!!

TO MODIFY THE RESET SCRIPT SETTINGS, USE THE FOLLOWING MENU OPTION:

CONFIGURATION -> AUTOMATED SCRIPT OPTIONS

"

the previous firmware and driver version usually has this warning, but P&E confirmed that this message about RESET SCRIPT is not intentional and has no impact. So this should not create any problems.

refer:

https://community.nxp.com/message/632961

2. please make sure "skip all breakpoints " is unchecked

3. try to update your KDS P&E driver to the latest

PEMicro - http://www.pemicro.com/eclipse/updates

if the problem is still unsolved. please show your connection message and list what board do you work with, we will check it further.

Have a great day,
Jennie Zhang

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

bonzo · ‎12-14-2016

I have the exact same problem when using uTasker. With KSDK, I don't see this issue--it seems to be related to uTasker.

I have tried both a FRDM-KL26 and TWR-K21D50M. I have used both OpenSDA and with a PE Multilink Universal debugger.

mjbcswitzerland · ‎12-19-2016

Jennie

The problem is basically with all boards and multiple projects. The skip break points setting doesn't have any effect.

This is something that I am now trying to get to the bottom of because it is starting to cause real problems in various product developments - in all cases the code runs normally and running between breakpoints is basically Ok , as is single stepping code, but as soon as the target is left to run the debugger starts losing connection.

This is something that I am seeing on a KL25, for example. All is find until I command a RUN and then I get this (note that the board is running correctly when it happens but the debugger seems to believe that it has halted it for some reason):

This means that it is no longer possible to pause the operation or set new breakpoints etc. It is only really possible to command a restart. Sometimes a restart command allows it to reset and begin again but often there are errors and it has to be disconnected to start from scratch again.

In the breakpoint window there is also this strange temporary breakpoint which the debugger "thinks" that it has hit (the second is a real breakpoint at the start of code to help stopping it run out of control after a restart command):

If I disable the strange breakpoint it still behaves the same. And if I command a restart it re-inserts the breakpoint in the list again.

The breakpoint address is in SRAM. It is very close to the stack pointer value that is loaded from the reset vector (which is 0x20002ff0), in fact 64 bytes lower than it.

I don't know where this breakpoint comes from or whether it is the cause of the difficulties but the fact is that it is IMPOSSIBLE to halt running code and this is the only hint that is coming from the debugger that is visible.

When the restart fails the error that is seen is :

Program received signal SIGTRAP, Trace/breakpoint trap.
Quit (expect signal SIGINT when the program is resumed)
Quit (expect signal SIGINT when the program is resumed)
Quit (expect signal SIGINT when the program is resumed)
Quit (expect signal SIGINT when the program is resumed)

This however seems to be a separate issue since it is random (doesn't always happen) but is possibly still related to the first issue in some way.

Regards

Mark

P.S. This is the connection message when downloading and stopping at the entry point.

Connection from "127.0.0.1" via 127.0.0.1
Copyright 2012 P&E Microcomputer Systems,Inc.
Command Line :D:\Freescale\KDS_v3\eclipse\plugins\com.pemicro.debug.gdbjtag.pne_2.3.6.201602211227\win32\pegdbserver_console -device=NXP_KL2x_KL25Z128M4 -startserver -singlesession -serverport=7224 -interface=OPENSDA -speed=5000 -port=USB1 -configfile=C:ø

CMD>RE

Initializing.
Target has been RESET and is active.
CMD>CM D:\Freescale\KDS_v3\eclipse\plugins\com.pemicro.debug.gdbjtag.pne_2.3.6.201602211227\win32\gdi\P&E\supportFiles_ARM\NXP\KL2x\freescale_kl25z128m4_1x32x32k_pflash.arp

Initializing.
Initialized.

;device freescale, kl25z128m4, 1x32x32k, desc=pflash

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

Loading programming algorithm ...
Done.
CMD>EM

Erasing.
Module has been erased.
Reloading programming algorithm ...
done.
CMD>PM

Programming.
Processing Object File Data ...

.
Programmed.
CMD>VC
Verifying object file CRC-16 to device ranges ...
block 00000000-000000BF ...
Ok.

block 00000400-00007430 ...
Ok.

block 00007434-0000744C ...
Ok.

Checksum Verification Successful. (Cumulative CRC-16=$5AFD)

CMD>RE

Initializing.
Target has been RESET and is active.

WARNING - NO RESET SCRIPT FILE HAS BEEN CONFIGURED TO RUN!!!

TO MODIFY THE RESET SCRIPT SETTINGS, USE THE FOLLOWING MENU OPTION:

CONFIGURATION -> AUTOMATED SCRIPT OPTIONS

Preset breakpoint encountered.

{

mjbcswitzerland · ‎12-19-2016

Hi

I have had a period where debugging was possible. To allow this to operate the following changes were made to the project configuration:

- Interrupt vectors were left in Flash (and not re-located to SRAM)
- Low power support disabled (moving to WAIT mode when no tasks ready to run)

Experimenting with settings suggest that programs with interrupts operating in SRAM could cause problems. Locating to SRAM with low power mode disabled in fact didn't allow the debugger to operate AT ALL - the code would immediately run after download and could not be paused... But running from SRAM with low power mode enabled allowed it to stop on connection but then have the usual run difficulties.

KDS crashed during some of the testing and wouldn't allow any further debugger operation so I had to stop and probably need to reboot the PC to recover but this is suggesting that there are real problems for some projects - not that they use bad code but they do certain "normal things" with the processor that the debugger can't tolerate. I will have these verified in a number of other developments in progress to see whether it can be verified and defined more accurately.

Regards

Mark

mjbcswitzerland · ‎12-19-2016

Update:

After rebooting the PC (KDS had crashed and things were unstable) I now look to get reproducible results on both a KL25 and a K64

1. If low power mode is being used (WAIT mode entered whenever there is no tasks pending) the debugger will not allow pausing code that is running and needs to be restart or disconnected to work again.
2. A repeat of tests this time didn't show any dependence on whether interrupt were in SRAM or in Flash (maybe a KDS stability issue at the time, looking to give this dependency).

This low power configuration has been used in the project for 12 years on Coldfire devices and since the first days of KDS (3 years?) without this debugger issue being recognised so it looks to be something new in the a recent KDS release.

The low power configuration typically halves the current consumption of the processor with no impact on performance and response.

Regards

Mark

ZhangJennie · ‎12-19-2016

Hi Mark

it's not possible to debug any of the low leakage power modes because the debugger looses connection (The debug port is completely off in these low power modes).
This applies for LLS, VLLSx modes.

Although you will be able to restore communication when LLS is exited or you can step over the code line to enter LSS and keep debugging (this keeps the device from entering the low power mode)

Refer to the attached presentation and lab for debugging low power modes, specifically to slides 17-26

the demo is made under CW but the method is the same for KDS.

Have a great day,
Jennie Zhang

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

mjbcswitzerland · ‎12-20-2016

Hi Jennie

Thanks for the presentation material.

However I still don't think that this is the problem since we are talking about WAIT mode and not low leakage modes, where some debugger difficulties are to be expected (and accepted).

The exact same build (or even exact same binary image on the boards) can be debugged without any difficulties if IAR or Keil (same P&E OpenSDA debugger on the board) are used. It is only the KDS users who are pulling out their hair at the moment, not other IDE users. This points to a weakness/bug in KDS and not a basic debugger issue or something that has to be accepted when WAIT mode is made use of. Note also that I don't remember such difficulties in previous versions of KDS.

I will repeat some tests with CW10.x and Atollic for comparisons to see whether these could be used instead.

Regards

Mark

mjbcswitzerland · ‎12-20-2016

Hi Jennie

I just imported the same projects (K64 and KL25 boards) into CW10.6 and I can debug with no problems on both when using the low power mode configuration.

This issue looks really restricted to KDS !!!

In fact I have observed the following:

1. When I start the system without an low power operation (remains in RUN mode) all works normally. The debugger sows that the target is running and offers the pause button and I can pause the operation as I want.
2. When I now command the WAIT state to be used when there are no tasks to operate the debugger changes to display that the target has paused (the HW is still running), it no longer offers the pause button and all over the place it is showing this strange breakpoint address (0x20002fb0) in all registers.
3. If I now command that the WAIT mode is no longer used (RUN mode only) I can click the restart button and the debugger shows that the target is running and I can also pause again.
4. If however I try to restart while the low power operation is still valid (WAIT mode used whenever possible) I tend to lose contact with the debugger and have to disconnect and start again.

Apart form 4. which can be a little random the rest is 100% reproducible with KDS. CW6.4 doesn't have the issue (nor does IAR or Keil).

Regards

Mark

ZhangJennie · ‎12-23-2016

Hi Mark,

Sorry for the delay. I was not in office. Can you please send me your demo code under KDS? I will check it directly once I arrive office on Monday. Thanks!
Have a great day,
Jennie Zhang

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

mjbcswitzerland · ‎12-23-2016

Jennie

Thanks - I have sent you details in a private message of how to download and use the V1.4.11 project at http://www.utasker.com/forum/index.php?topic=1721.0

It is set up for FRDM-K64F and KDS by defaults but you can also try CW10.4 if you like (or IAR, Atollic, Keil etc.) which don't have the issue.

If you can identify the cause it would help out in a number of product developments that presently have the problem.

Regards

Mark

ZhangJennie · ‎12-29-2016

Hi Mark.

I download your demo project but can't unzip it. No password

Thus to simplify the issue, I did a demo code under KDS3.2 for wait mode testing(attached demo code). here is my testing result:

1. in RUN mode (no WAIT, no other low power mode), the power current is 14.2mA. debug work normal.

2. in WAIT mode, when connects with KDS debugger, the power current is 12.7mA. all the debug buttons (single step, pause, run...)function normal.

please check if it is same on your side. and how to modify my code to reproduce the issue?

Have a great day,
Jennie Zhang

mjbcswitzerland · ‎12-29-2016

Jennie

I had sent details and a password in a private message.
I have just sent this again.

The WAIT low power test in KDS3.2 is extremely simplistic and may not represent real applications based on its use, which are randomly switching between WAIT and RUN mode - possibly many thousands of times a second.

By default the uTaskerV1.4.11 project is configured for the FRDM-K64F with low power active. To disable the low power support, comment out SUPPORT_LOW_POWER in \Applications\uTaskerV1.4\config.h

Regards

Mark

mjbcswitzerland · ‎01-03-2017

Hello Jennie

Have you received the password in the meantime and been able to extract the project?

As noted before, this project shows a weakness in KDS (CW, IAR, Keil, etc. don't have issues with it). Your simple WAIT mode test doesn't test switching between modes and so is not representative of a dynamic WAIT mode utilisation and so doesn't help to identify the problem.

Thank you in advance - there are a number of project where this is causing problems and KDS either can't be used or the WAIT mode has to be disabled in order to be able to debug with it.

Regards

Mark

P.S. In case there are problem with private mail please use m personal email address (mark AT uTasker.com)

ZhangJennie · ‎01-04-2017

Hi Mark,

Yes, I received it. I Was occupied by some urgent work these days. I will check this issue as early as possible these days.

Best Regards.

Jennie Zhang

mjbcswitzerland · ‎01-13-2017

Hi Jennie

I hope that you are progressing well with your work. Do you know when you will be able to look into the issue. We have verified it in a large number of projects now and always have to (temporarily) disable WAIT mode operations in order to be able to work properly. The same projects (with WAIT mode enabled) do not have any problem if CodeWarrior 10.x is used instead.

The hope is that if you (as NXP worked) can reproduce the same problem the issue may be taken seriously as a weakness in the KDS version - or a workaround can be identified.

Regards

Mark

ZhangJennie · ‎01-15-2017

Hi Mark,

It's strange, I truly posted my reply here with a video on 2017-01-06 afternoon, but I don't know why it is not showup here. I will check again and reply soon.

Have a great day,
Jennie Zhang

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

ZhangJennie · ‎01-16-2017

Hi Mark.

In order to solve the problem, I tried to reproduce the problem first.

I opened your project with KDS3.2.

According to the information you provided "By default the uTaskerV1.4.11 project is configured for the FRDM-K64F with low power active. To disable the low power support, comment out SUPPORT_LOW_POWER in \Applications\uTaskerV1.4\config.h"

I think the default project is wait mode and I should reproduce the halt button problem with it without change any of your code. Right?

Thus I build and download with OpenSDA P&E interface to FRDM_K64 board,.

after launch debugger, I step over code, full run code, then press "halt" button, It works as I expect. see video I recorded on 6.

Today, I tested your project again on both my colleague and my computers with OpenSDA Jlink interface. it is the same.

(BTW, when my colleague tested your code, the program failed to download first time, show "no source available for ..." because forgot selecting target chip, after have it select, there is no problem to download and debug.)

where did I misunderstanding? How to reproduce your problem with your code?

Have a great day,
Jennie Zhang

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

mjbcswitzerland · ‎01-16-2017

Hello Jennie

Many thanks for testing. I think that the difference is in the fact that you import into an existing environment .
I have made a similar video at :

https://www.youtube.com/watch?v=ttuY0x7YpwA

which shows a fresh import into a new work-space. Note that I have to also create a debug target and that after loading and running the code I cannot do anything else and have to disconnect the debugger.
It may be that when you import into an existing environment it inherits something, or it may be that your environment has different plug-ins, etc. The question is why a basic KDS3.2 installation doesn't run?
If you repeat as I did you should be able to reproduce the issue.

Thanks

Mark

ZhangJennie · ‎01-17-2017

Hi Mark,

This time I created a brand new workspace then imported your project to it. see attached video (2017-01-17_16-29-43). because our community doesn't allow attachment over 10M thus I split it into two parts with zip. please download both 2017-01-17_16-29-43.zip.001 and 2017-01-17_16-29-43.zip.002 to a same folder then unzip it to one file: 2017-01-17_16-29-43.mp4.

I install KDS3.2 with some updates: P&E updates and KDS updates. I made video for you to show my updates install.

I suggest you perform menu "help", "Check for updates" to install all of them.

Please let me know if where I am wrong or if your problem can be fixed after install the updates.Thanks!

Have a great day,
Jennie Zhang

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

mjbcswitzerland · ‎01-17-2017

Hi Jennie

I checked for updates and it installed new "GNU PEMicro Interface Debugging Support" and now it is possible to debug the project!

This has taught me an important lesson:

- Although I installed KDS3.2 before trying it doesn't mean that it has latest drivers or plug-ins - therefore always check for updates immediately

I will now inform all users to do the same to verify that there are no further issues.

Thanks!

Regards

Mark

Is there an explanation for the following debugger behavior??

Is there an explanation for the following debugger behavior??

General