USBDM, KDS, MKE04, debugging stuck

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

USBDM, KDS, MKE04, debugging stuck

Jump to solution
1,967 Views
jaromirsukuba
Contributor II

Hello,

I'm trying to set up debugging with KDS3.2 and USBDM, plus DIY board with MKE04Z8VWJ4 part and LED attached to PB5 pin (along with decoupling capacitors and pull-up on RESET line).

I installed both components, set up project in KDS that blinks a LED, compiled binary and this binary can be loaded into MCU using "ARM programmer" component with no problems - see screenshot here - the LED blinks as expected.

When I set debug configuration to USBDM - see here - and start debugging, something strange happens. The debugger isn't stopped at main, but on first instruction after reset. See screenshot of KDS here. When I hit Resume (F8) LED blinks - indicating the debugger set MCU to run. After hitting suspend, the LED stops blinking, but current location displayed is still on first instruction after reset. I'm not sure how can I fix it.

I know this information is quite sparse, I can provide more screenshots/logs/whatever when needed.

The program to blink a LED looks like this:

#include "MKE04Z4.h"

static int i = 0;
static unsigned long cnt;

int main(void)
{
    GPIOA_PDDR = (1<<13);
    GPIOA_PDOR = (1<<13);
    for (;;) {
        for (cnt=0;cnt<500000;cnt++);
        GPIOA_PSOR = (1<<13);
        for (cnt=0;cnt<500000;cnt++);
        GPIOA_PCOR = (1<<13);
        i++;
    }
    return 0;
}

1 Solution
1,485 Views
pgo
Senior Contributor V

Hi Jaromir,

I have not had a chance to look at the log yet, however I have spotted something that appears strange.

When I run the debugger it is configured to run the the GDB included in KDS or explicitly set to a separate installed GNU ARM Embedded Toolchain.

In either case, when running, the debugger shows something similar to this:

pastedImage_1.png

You note that the GDB is explcitly being executed by a complete path.  It is also the "arm-none-eabi-gdb" version as required.

Your screen grabs show:

pastedImage_2.png

I suspect your have another version of GDB installed on your machine that is being executed in preference to the correct one - probably for a different processor.

Can you make sure you have configured USBDM correctly:

USBDM->Configure

pastedImage_3.png

If this has no effect, please review your PATH variable in windows.  If you can locate another version of GDB (e.g. MINGW) try temporarily renaming the executable to see if it affects the problem.

bye

View solution in original post

10 Replies
1,485 Views
pgo
Senior Contributor V

Hi Jaromir,

I do not have a MKE04Z8 for testing but I used a 9SKEAZN8 which I believe is the same silicon but with different qualification.

I used the following hardware:

pastedImage_1.png

I used the following program:

#include "MKE04Z4.h"

static int i = 0;
static unsigned long cnt;

#define LED (1<<(8+1))

int main(void) {
   GPIOA_PDDR = LED;
   GPIOA_PDOR = LED;
   for (;;) {
      for (cnt=0;cnt<500000;cnt++);
      GPIOA_PSOR = LED;
      for (cnt=0;cnt<500000;cnt++);
      GPIOA_PCOR = LED;
      i++;
   }
   return 0;
}‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

I created a USBDM project and a Kinetis Procesor Expect Project for a MKE04Z4 using the above program (or with minor mods).  For the PE project I added a USBDM launch configuration from the right-clock menu:

pastedImage_5.png

Testing was done with:

  • USBDM_SWD_SER_JS16CWJ
  • USBDM V4.12.1.180 (Should be equivalent to the latest release (V4.12.1.170) as far as MKE targets are concerned.
  • KDS V3.2
  • Firmware was updated to the version shipped with the above.

The two projects worked as expected when debugged.

Can I make sure that you are using the latest version of the USBDM software and you have updated the firmware on the BDM to the current version?

In addition, if this does not help please provide the following information:

  • Hardware being used e.g. USBDM_JS16 etc
  • Provide the circuit for your minimal test hardware.

Thanks

0 Kudos
1,485 Views
jaromirsukuba
Contributor II

Hi pgo,

thank you much for your insight. I updated the firmware in my debugger. Before and after - here you can see firmware/software revisions as well as debugger variant.

My hardware is pretty much the same as yours. Pin 9 of debug header is grounded too, there is also 47uF electrolytic bulk cap on power rails, 15kOhm pull-up on RESET line. Led is on PB5.

The results are pretty same as before, though. The LED is blinking when I hit Resume, but when I press Suspend, debugger points to first instruction after reset handler (0x4e9), single stepping never finishes. When I set up breakpoint to main loop and hit Resume, it stops (apparently on given breakpoint, after every blink of LED), but PC is still shown as 0x4e9. The PC shown in debugger is just stuck at 0x4e9. I can watch variables (for example i in my source is incrementing after every blink of LED) too. I feel like I'm not far from results, but still not there.

In the meantime I played with raw ARM GDB and can't find anything that doesn't work.

Could you, please, share your project?

0 Kudos
1,485 Views
pgo
Senior Contributor V

Hi Jaromir,

Attached are the two projects exported from KDS.

I have also tried reverting to USBDM V4.12.1.170 and it still works as expected.

  • Could you increase your communication speed to 12 MHz if already at that value.

If you still don't get the expected results could you try the following which might indicate where the problem is occurring:

  • Make sure the GDB server is not running. It doesn't matter if KDS is already running.
  • Manually start the Debug version of the GDB server from the installation directory e.g. C:\Program Files (x86)\pgo\USBDM 4.12.1.170\UsbdmGdbServer-debug.exe
  • In the opening dialogue detect the connected device and make sure the other settings look appropriate.  Click Keep Changes
  • Debug one of the attached programs in KDS in the usual fashion but exit the debugger as soon as you see incorrect behaviour (to reduce the overwhelming log!)
  • Close the GDB server.
  • This will produce a log in %APPDATA%\usbdm\GDBServer.log
  • Please post this log file. 

I can then compare the log to the results I obtain on my machine.

You can also check that the USBDM plugin is being updated correctly:

  • Help->About
  • Select the Cog Wheel

pastedImage_1.png

  • Select Plug-in Details

  • Post a screen-grab of the plugin versions

bye

0 Kudos
1,485 Views
jaromirsukuba
Contributor II

Hello,

thank you for your tremendous effort and support.

I tried to open your example, namely the MKE04Z8_PE project. Ran debug under "MKE04Z8_PE_Debug_USBDM" configuration and got exactly the same results as I had with my own project/debug configuration. Program pointer in debugger (green line) is stuck at first instruction after reset handler, no matter what - see here.

I did screenshot of plugin-details, see here, please. Does the version number look right? Running the GDB server manually, it reports version number 4.12.1.170 as on picture here.

I changed communication speed to 12MHz on my project (yours was already at 12MHz), with no difference. I experimented with other communication speeds before.

Then I ran the GDB server as per your instructions to obtain logs. The project I ran was your MKE04Z8_PE, unmodified, with the same debug profile settings.

The logs are here : LOG - the scenario was as follows: I ran server, ran debug from KDS, hit Resume button, left it running for a second, hit Suspend button, saw the program indicator being still on first instruction after reset handler, stop debug session, stop debug server.

0 Kudos
1,486 Views
pgo
Senior Contributor V

Hi Jaromir,

I have not had a chance to look at the log yet, however I have spotted something that appears strange.

When I run the debugger it is configured to run the the GDB included in KDS or explicitly set to a separate installed GNU ARM Embedded Toolchain.

In either case, when running, the debugger shows something similar to this:

pastedImage_1.png

You note that the GDB is explcitly being executed by a complete path.  It is also the "arm-none-eabi-gdb" version as required.

Your screen grabs show:

pastedImage_2.png

I suspect your have another version of GDB installed on your machine that is being executed in preference to the correct one - probably for a different processor.

Can you make sure you have configured USBDM correctly:

USBDM->Configure

pastedImage_3.png

If this has no effect, please review your PATH variable in windows.  If you can locate another version of GDB (e.g. MINGW) try temporarily renaming the executable to see if it affects the problem.

bye

1,485 Views
jaromirsukuba
Contributor II

Hi pgo,

you are correct,

I had indeed incorrect GDB server specified. Or more specifically, there was PATH NOT SET field in ARM tools path textbox, so the it debugger grabbed first GDB available, apparently for different platform. Honestly, I didn't know there is explicit need to configure path to GNU tools that came with KDS.

I manually set path for ARM GNU tools contained in KDS and now everything seems to work just right.

Thank you much for your support, it was really helpful.

0 Kudos
1,485 Views
Alice_Yang
NXP TechSupport
NXP TechSupport

Hello Jaromir,

Please try to"Set temporary breakpoint at"  main, and uncheck the "Start execution after load" :

pastedImage_1.png

If still can't work , please let me now, I will help you to porting this question to the USBDM part .

BR

Alice

0 Kudos
1,485 Views
jaromirsukuba
Contributor II

Hi Alice, thank you for your prompt response.

Unfortunately, unchecking those options doesn't help much. In fact, situation is the same as before.

I feel like there is something wrong with USBDM GDB server, or at least with my setup. I closed the KDS, ran the GDB server manually (the MKE04 part was normally detected) and then executed arm-none-eabi-gdb manually. Set up target to localhost:1234 I can halt/reset the target, but after issuing cont command, the server unexpectedly returns SIGINT signal and PC stays at the same address as with KDS, though I can normally view content of registers - see screenshot here.

It looks like this problem is more USBDM than KDS related. Please, could you help me moving this to more appropriate forum?

0 Kudos
1,485 Views
jaromirsukuba
Contributor II

Another update. Manually loading the elf file into GDB (with USBDM GDB server running and attached) works, then running and stopping the target, works as expected, see screenshot here.Sorry for the noise, GDB server seems just fine.

I can't see anything that is wrong, but the integration with IDE seems broken.

0 Kudos
1,485 Views
Alice_Yang
NXP TechSupport
NXP TechSupport

Hello Jaromir,

I have porting your this case to the OSBDM space, there are USBDM expert will help you .

BR

Alie

0 Kudos