Problems programming a KL17Z from a FRDM-KL27Z board

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Problems programming a KL17Z from a FRDM-KL27Z board

629 Views
rlgagliardo
Contributor I

Hello,

 

I’m having issues using the MCUXpresso IDE to program a KL17Z64 type MCU on a custom board via the SWD interface.

 

Setup:

I’ve purchased a FRDM-KL27Z eval board and installed a header/jumper on J18 (and cut the trace between pins 1 and 2 of that connector). I also installed J11 and have a 6 inch ribbon cable from J11 to a similar connector on my custom board. The MCU on the custom board is less than 3/8” from the header and SWD_CLK and SWD_IO go directly from the MCU to the header. I have a 10K pullup on the SWD_DIO line and a 10K pulldown on the SWD_CLK line. Note that reset is not connected to my target processor – I’ve used a FRDM-KL02Z eval board to program a number of custom boards and found that the reset line often causes issues. The SWD protocol tends to reset the processor as part of the communications anyway.

 

Observations:

When I install the jumper on J18 and unplug the ribbon cable from the FRDM board, I can program the processor on the FRDM board successfully. When I install the ribbon cable and remove the jumper the target fails to connect. I’ve verified that the processor is not in reset, is powered on, and that the DIO and CLK lines are properly connected.

Attached is a scope trace with the SWD_CLK line on CH2 (green) and SWD_DIO on CH1 (yellow).

Note that the spikes have more to do with the fact that I’m using a standard scope probe with a ground wire – it looks ugly but isn’t the issue. The data on CH1 (yellow wave) shows what looks to be the issue. I assume the curved portion is the target processor response: it looks like there is a significant amount of capacitance on the cable. Is that normal and is there a way to clean that up?

Labels (1)
Tags (1)
0 Kudos
Reply
1 Reply

616 Views
jingpan
NXP TechSupport
NXP TechSupport

Hi rlgagliardo,

Maybe you picture is not a problem. Because in SWD protocol there is a one clock turnaround period. This is a period during which the line is not driven and the state of the line is undefined. You can refer to IHI0031A_ARM_debug_interface_v5.pdf.

I guess there is other hardware problem.

 

Regards,

Jing

0 Kudos
Reply