FRDM-KL26Z DOA

[Frotz]

Hi,

Got a FRDM-KL26Z from Digikey and it's dead on arrival. Connecting the device to power via USB reveals no activity. Documentation indicates that there's a demo onboard. No evidence of any such thing with this board. Connecting it to a Mac and running USB Prober reveals that there's no device connected to the Mac. No activity on the board when powered in any way. No MSD. No change when holding down reset.

Digikey was very kind to send a replacement. It's just as useless.

What's the deal?

Thanks,

Andre.

[ErichStyger]

Hi Mark,

No pact with the devil at all, just having a friend somewhere who allows you to plug in that board. I would offer my machine at least.

The reality with these things is imho: the more diversity you have (machine types, debug probes, ...), the better.

Erich

[Frotz]

One more thing: 

Should have mentioned that first flash was with USB connected to KL26's USB port and second flash was with USB connected to K20's USB port.

[mjbcswitzerland]

Hi

The FRDM-KL26Z is quite an old board and often stocks are also old and still programmed with a version of debugger that gets killed when connecting to MAC or Win 10 (due to a change that the OS manufacturers made on connection of external hard drives).

Updating the debugger firmware should solve it but this needs to be done with an older PC like Win 7.

Take a look at Erich Styger's blogs since he have a number of entries about recovering boards:https://mcuoneclipse.com/

The debugger firmware is available via this link, which also contains some instructions: https://www.nxp.com/design/microcontrollers-developer-resources/ides-for-kinetis-mcus/opensda-serial...

Regards

Mark
[uTasker project developer for Kinetis and i.MX RT]
Contact me by personal message or on the uTasker web site to discuss professional training, solutions to problems or rapid product development requirements

For professionals searching for faster, problem-free Kinetis and i.MX RT 10xx developments the uTasker project holds the key: https://www.utasker.com/kinetis/FRDM-KL26Z.html

[Frotz]

Hi Mark,

I was very careful with the second board to first plug it into power via USB (observing ESD precautions) with no computer in sight using a Petzl headlamp charger and appropriate cable. No demo. No blinking green LED beside the OpenSDA chip indicating some error or even lighting for a moment. No bootloader needed to follow the procedure at: https://www.nxp.com/design/microcontrollers-developer-resources/ides-for-kinetis-mcus/opensda-serial...  or Erich's procedure at: https://mcuoneclipse.com/2018/04/10/recovering-opensda-boards-with-windows-10/ Nothing. At the very least applying power to the board should cause the demo to run. I'd say there's no firmware anywhere. 

I've had a look at the other threads regarding this board and their experiences do not match mine. All of them had some response from the board initially—a green LED, MSD mounting etc. These two boards never showed the slightest response to power or power+data. 

Poking around with an old HP LogicDart shows the OpenSDA SWD port is triggering a reset pulse at 72kHz, there's nothing from the 8MHz oscillator to the KL25, but there is power.

What's the problem?!

Thanks very much,

Andre.

[Frotz]

Thanks Mark & Erich,

Turns out the KL26 can be programmed using an external DAP (I used my cheapest in case it blew-up: the MAXDAP from Maxim) and just pressing the SWD header against the pads (super helpful cheap-n-cheerful tip, Erich!) on BOTH boards. Clearly they were not programmed or they "lost" their programming somehow.

There are indeed more interesting parts, but the KL26 is the right size (QFN 32) right peripherals (Self-Cap TSI, SAI & the usual suspects) and right memory/performance (128/16@48MHz) for the application. Mark, if you know of something ARM based with similar specs, I'd love to hear about it!

So how do I now program the KL20? In reading posts of others with damaged FRDM-KL26Z boards I seem to remember that the KL20 can't be reprogrammed via SWD because mass erase is disabled in the chip. At any rate, I've no access to a windows machine!

Thank you both very kindly,

Andre.

[ErichStyger]

Hi Andre,

as Mark said: I would  connect a 10 pin SWD header on J7 if you happen to have an external debugger (e.g. J-Link: that way you can program/debug the KL26Z, but not sure if this is worth the effort.

You actually don't need to solder the header: just pressing it against the pads should give you a good enough connection to try it out.

I suspect that maybe the K20 is not programmed (not sure why). In that case you can use the same approach and programm/flash the firmware image to it, because then  it would not be protected by the bootloader and you can use it as you want.

In any case: I'm wondering what kind of testing they do at the factory?

As Mark said: there are more interesting parts, so you just might need to move on.

I hope this helps,

Erich

[mjbcswitzerland]

Andre

I have had a FRDM-KL26Z board die on me (too) and ordered a new one but I never tried repairing the failed one.
My suspicion is that the USB power supply failed so you can check the voltage there to see whether there is a problem with the the series diode, for example (couldl be a problem restricted to the OpenSDA part and not the KL26).

I also have freedom boards where the OpenOSD part failed and I keep backups of the 0.5" headers that I can solder in when needed to move to an external debugger.

In your case it would be very unlucky to have two fail (in my case I have probably about all of the approx. 50 different Freedom (and similar style) boards and had around 5 fail in 9 years).

If you don't find a solution it may be worth going for a different board since the KL26 is stone age now and there are more interesting newer parts - also look at a cheap i.MX RT 1010 board which will give you 500MHz for about the same price.

Regards

Mark

P.S It is normal to have a saw tooth signal on the reset line when the KL26 is not programmed. This is its internal watchdog triggering over and over again (each several hundred clock cycles) and driving the reset as output. It is not the OpenSDA debugger doing this.