Problem using SWD with new KL02 and KL25 chips

[uribendelac]

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:

Kinetis KL05 SWD Connectivity Problems

Cannot program New MKL25Z128

KL26 not responding to SWD

Interesting reset activity on RESET_b for KL26

Can FRDM-KL25Z be used with KL02?

Re: Unable to debug MK22FN1M0VLH12

MK20DN128VFM5 - SWD Does not connect

If anyone can shed a light on this and come up with advice that actually works, it will be much appreciated.

Uri

Update:

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.

Uri

[uribendelac]

I can confirm my assumption raised in my last post:

I have just built another board based on the KL25Z128VFM4 chip, using the bare minimal connections as listed in my previous post. I tried connecting to it from a FRDM-KL25Z board with the MBED firmware (mbed 20140530_k20dx128_kl25z_if_opensda) and with KDS, but KDS could not connect to the board. I then swithed the FRDM-KL25Z firmware to the PEMicro one (V102), and could use CodeWarrior to connect and burn an image to the board. Once initialized, I could revert to the mbed image and use KDS again to access the board.

[george]

Dear Uri,

We are also continuing analysis about four weeks on the same issue as you.

However, we cannot find that root cause and workaround yet.

The device which we use is MKW 01Z128.

Very many these similar issues are on this Community.

I also think that this is a very strange and provoking issue as you say.

If this is read, please let me know one.

What kind of issue is the soldering problem which you found on the latest board using KL02Z32VFM4?

* It may become our reference.

Best Regards,

George

[uribendelac]

Hi George,

Since my last post, I have mounted one more board and it worked correctly from the beginning. See my summary in last post for what I use. To operate an ARM core over SWD, you just need to provide the ARM with power, at least one ground, SWD_DIO, SWD_CLK and reset. Since reset on the Kinetis cores behaves as both an input and an output, it needs to be pulled up (I use 10K) but WITHOUT the usual capacitor to ground. As for SWD_DIO, it needs to be pulled up, which is usually done inside the silicon (read datasheet and verify with scope). According to the SWD spec, the SWD_CLK should be pulled down, also usually done in silicon, but it will equally work with a pull up, since it is just to force a known state when nothing else is connected to this input. Finally, it is possible (though I am not sure) that you will need to use CodeWarrior (rather than KDS) for the first time you program the chip, as I have found it to be more robust than KDS in that regards.

On the last board I had a problem with, the SWD_DIO was not properly soldered, which I noticed with a scope that showed the line was not being pulled up.

Regards,

Uri

[Carlos_Mendoza]

Hi Uri,

Thank you for posting your findings and how you fixed the communication issue, it is good to hear that it was solved.

Please let us know if you run into any other problem.

Best Regards,

Carlos Mendoza

Technical Support Engineer