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;
}
已解决! 转到解答。
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:
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:
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
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
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:
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:
Testing was done with:
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:
Thanks
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?
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.
If you still don't get the expected results could you try the following which might indicate where the problem is occurring:
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:
bye
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.
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:
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:
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
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
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.
Hello Jaromir,
Please try to"Set temporary breakpoint at" main, and uncheck the "Start execution after load" :
If still can't work , please let me now, I will help you to porting this question to the USBDM part .
BR
Alice
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?
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.