USBDM how to debug KL25Z

[galadragos]

Hi!

I'm trying to use USBDM to debug a KL25Z128 target, via OPENSDA USBDM interface and eclipse.

Programming works, initial setup works, but I have one BIG PROBLEM, and is called INTERRUPTS !

No matter what I've tried all my interrupts are disabled the moment I enter debug mode !

I've configured the micro peripherals not to disable interrupts during debug (timers, adc, ...) but I still can't get in a interrupt during debug, and INTERRUPTS ARE NOT EXECUTED !

What is the point of a debugger, if it modifies the program so much that is unusable ???

How the heck do you debug using USBDM ?

[galadragos]

I can now confirm that ALL NVIC INTERRUPTS are being disabled automatically when debugging with USBDM.

Just try to enable an interrupt, say the ADC, when you debug the target with USBDM and check the NVIC_ISER or NVIC_ICER registers. They are ALL ZERO, when they should have a 1 in bit 15 position!

Hence all NVIC interrupts are DISABLED BY USBDM.

I've tested the hardware fault interrupt, and it is working in debug mod as well. Also NMI behaves correctly.

Something that USBDM does, or does not, disables the NVIC.

[pgo]

Hi Dragos,

I do most of the USBDM testing on a MK20DX128M5 and have no problems with interrupts.

Could you create a very minimal test case in eclipse, export it and post it here and I will see if I can find what the problem is.

USBDM does not (intentionally) modify the NVIC registers.  It may modify the MISC register when stepping to prevent interrupts on the initial step.

bye

PS.  Does the program run correctly when programmed using the stand-alone programmer?

[galadragos]

Finally! An answer !

Yes the program runs correctly when using the standalone programmer.

If I use another OpenSDA debugger, like JLINK, the program hits the interrupts in debug mode.

I'll see what I can do about that example.

[pgo]

Hi Dragos,

I tried a simple interrupt example program on a FRDM-KL25Z board using Eclipse+USBDM plugin+ARM-GCC and it worked fine.  Setting breakpoints in the interrupt handler showed that it was being executed.

I have attached the example.

bye

[galadragos]

Funny thing is that I've made an example and it works.

Your example also works.

However the program that I'm trying to debug is way bigger.

My example takes only 1064 bytes of flash, while my program takes 25976 bytes of flash.

Your example takes 2612 bytes of flash. (What is with the .size file? It should print the size, not save it !)

Thanks for the code, it gave me some ideas for future projects.

I have attached my example.

I use plain eclipse, not CW 10.x.

Debugging my program is not working, even though the settings used to compile my program were used to compile my example.

[galadragos]

Done another eclipse project and imported just the source code of my program. Still no IRQ.

[pgo]

Hi Dragos,

I suspect the interface is not handling the device going into low power mode.  I haven't used the very low power mode so they haven't been checked.

I will have a look and see if I can improve this.

bye

[galadragos]

I'm not using any low power modes that I know of.

Aside from the gpio, cpu init and timer functions from that example, I use the 3 uart modules and the adc, all in interrupt mode.

[pgo]

Hi Dragos,

I tried the project you uploaded but I had to replace the clock code before it would run.  I'm not sure why this was the case.  Anyway, after doing this the interrupts seemed fine.

I have attached another test program just to demonstrate a more thorough test.  It uses the following:

• RTC with interrupts
• PIT with 2 channels with interrupts
• FTM with 2 channels in output-compare mode with interrupts
• PWM with two channels (without interrupts)
• LPTMR with interrupts

These all work with Eclipse+USBDM Eclipse Plugin+USBDM GDB server+FRDM-KL25 with USBDM OpenSDA firmware + Windows 7.  I'll try it with Linux over the weekend

You can't do much debugging except by setting breakpoints in the handlers.  A pain with KL25 since it only has two of them.

bye

[galadragos]

The clock code was actually generated by Processor Expert. Something is fishy here.

I'll give the code a try as soon as I have time.

Low on breakpoints? Try __asm("bkpt"), but all you will get is a hang in that spot.