I have been using both a KL25Z128VFM4 and KL02Z32VFM4 chips on custom boards for the last couple of months. I am using FRDM-KL25Z and FRDM-KL02Z and either CodeWarrior or KDS to debug those boards. I am observing a problem that I believe many others have encountered as well. There are various types of problems related to SWD operation - I am referring here to one particular type, which is using SWD to access a "fresh" new chip (at least of the types KL25Z128VFM4 and KL02Z32VFM4, which are the types I have tried). From my experience with about 6-8 boards I have brought up, each time I try connecting to the board through its SWD interface for the first couple of times, the communication fails as the microcontroller wiil not respond to the read IDCODE command due to it being stuck in an endless loop of resetting. I have tried several variations to the reset circuit, as well as pull-ups/downs on the SWD lines (as suggested in several discussions) without any success. Eventually, after many attempts that may span several days, eventually the board will respond and get programmed, and from then on there will be no more issues (of this kind) with it. The problem is I haven't been able to detect any pattern that leads to such success, which means every time I have a new board I have to potentially start experimenting with it for up to days at a time...needless to say very frustrating.
I have also written code to operate a SWD from GPIOs to issue the reset-switch2SWD-reset-readIDCODE sequence, so I could experiment with the timing of the various elements, but again without success (it gets the required response from microcontrollers that have already been programmed, but it will not be able to get any response from "virgin" microcontrollers).
Some previous discussions that seem to relate to the same problem:
If anyone can shed a light on this and come up with advice that actually works, it will be much appreciated.
The latest board I had a problem with was based on the KL02Z32VFM4. I have since built a new board based on the KL25Z128VFM4, and that board had no problem operating from the start. I went back to the KL02Z32VFM4 based board and found out I had a soldering problem. Once fixed, the board responded to the read IDCODE command, but CodeWarrior+FRDM-KL02Z was still not able to communicate with it properly. It turned out I had to remove a 0.1uF capacitor on the reset line, which apparently caused a timing issue. Without the capacitor I could access the board.
To summarize my findings so far, I use a minimalist SWD interface composed of only three lines, GND, SWD_DIO and SWD_CLK. The reset is not needed as it can be done in software through the SWD interface, and VCC is apparently not needed either. I also use a small (33 Ohm) series resistor on both SWD_DIO and SWD_CLK. The one for the CLK is not really necessary, but the SWD_DIO is there to protect the chip from damage that can occur when the SWD protocol gets out of sync and both sides think it is their turn to generate data, as can occur when the SWD debugging adaptor is either disconnected and reconnected or halted abruptly. The CoreSight DAP Light manual calls for the interface silicon to be built robustly to "tolerate short periods of contention". Since I have had a few cases in the past where a perfectly good working uC stopped responding to the SWD bus, and based on the voltage levels the SWD_DIO seemed damaged, I suspect the Kinect parts are in fact not totally immune to such a contention, so the series resistor may save them from damage. I also have ESD protection diodes on both lines. As for the reset, I now just have a pull-up with no capacitor. Hopefully this combination will prove to be consistently robust and reliable.