USBDM fails to issue reset or breakpoint to KL27Z256

[uribendelac]

Hi pgo,

I have been working for a while with USBDM and a KL27Z256 and it worked quite well - I flash the device with the stand alone ARM programmer (image mode) disabling the bootloader, and then connect to the target from USBDM without programming first, just issuing a reset and temporary breakpoint at main. I appreciate the fact that flashing is fast and that there is a peripheral view in the debugger.

But now, I can't properly connect to the target anymore. When I try, the target will continue running from where it was, without going through a reset sequence. I can halt the target and step, but if I issue a (USBDM) restart, it will behave as if I pressed continue. The only way I have found to start from the beginning is to manually load the PC and SP and step. breakpoints also don't seem to work anymore. I haven't found a way around this yet. Any idea how I can proceed?

Thanks,

Uri

P.S.

Another minor issue is that whenever I exit KDS, I get a crash message from "Microsoft Visual C++ Runtime Library" saying "This application has requested the Runtime to terminate it in an unusual way". This is unrelated to the above, and appeared also when USBDM was still functional.

[uribendelac]

Another observation I made is that sometimes, when I connect with USBDM, I see it is halted at a software breakpoint inside an infinite loop, running from internal RAM at address 0x1FFFFF88.

Hope that helps,

Uri

[uribendelac]

One more thing I need to clarify is that when I had the above mentioned problem in USBDM, I could still debug correctly from OpenOCD, so it had nothing to do with the image itself. Somehow, the original problem just went away from its own with new versions of the image. However, another observation I made and seems related is that it all points to a common source of problems I have already mentioned in the past - it seems USBDM can develop a list of "hidden" breakpoints that are not shown anywhere and will not be removed by clearing all breakpoints. When two of these phantom breakpoints exist, stepping and resuming will not operate correctly, and likely when such a phanrom breakpoint exists at the wrong location it can even prevent the debugger from running from reset as happened. What I would really like is a way of clearing this state information that USBDM holds, other than uninstalling and reinstalling USBDM.

Uri

[uribendelac]

OK, I think I figured out how the extra breakpoints got generated and how to remove them. When I add a breakpoint from the disassembly window, it does not always appear on the breakpoint list, and when it doesn't, it also does not get cleared when I do a remove-all on the breakpoint window. So the work around to this problem, when it happens, is to open the disassembly window and hope for the breakpoint to happen, so that it can be removed from there by clicking on it. The problematic situation, where there are phantom breakpoints not listed in the breakpoint list, can be diagnosed by USBDM complaining there are no more breakpoints when you try to add a breakpoint in some C/C++ file which should work but doesn't.

Uri

[pgo]

Hi Uri,

I posted a reply in another post of yours asking you to check the USBDM server window to see what it is trying to do in terms of breakpoints.

This would show the breakpoints being set and cleared and might indicate where the problem is coming from.  I would like to see what

break-points GDB is telling USBDM to set (which would be indicated in this dialogue).  This would confirm the location of the problem.

I will have another look at the break-point code and see if I can find a reason why it would not be keeping track of the breakpoints correctly.

Exhausting the breakpoints will prevent the reset code working as it tries to set a temporary break-point at main and if this fails the reset will be aborted.

I have tested on a FRDM-KL27 board but been unable to trigger the problem.

bye