Hi,
I've got a brand new FRDM-KL25Z which I've been trying to use with MCUXpresso, but I discovered it shipped with the old PEMicro firmware that doesn't work in 2019 (ie. only Win XP/7).
So, I downloaded the firmware update from PEMicro, read the PDF update instructions (which are wrong) and followed them. The computer I was using at the time was a Windows 10 PC. After copying the boot loader file and restarting the board I noticed the following:
* No lights / activity when connected to either the OpenSDA or USB ports
* In bootloader mode (ie. hold reset button) the D4 LED flashes 8 times rapidly every
* Tried to restore via Windows XP / 7 VM but bootloader update simply won't copy
* Tried under Linux and bootloader update file copies
* Now: no lights, no connectivity, no reset / bootloader mode
How can I get my board working?
And, is it normal for boards to come from NXP with ancient firmware that requires a ten year old computer to operate or it'll brick? Not to mention the ONLY accurate documentation for all this is some guy's blog. Sorry to say, but this is a terrible first experience for me, not happy at all, I just want to write some code ... not build a Win 7 PC. </rant end>
Please, please help.
Paul Swanson
PS. Yes, I've read: https://mcuoneclipse.com/2014/11/01/illustrated-step-by-step-instructions-updating-the-freescale-fre... AFTER it became clear that ALL supplied documentation from NXP & PEMicro was just plain wrong.
For posterity, I used a Windows 7 PC and following the steps outlined in the blog successfully update the board.
Hi Paul Swanson,
Please refer: Bricking and Recovering OpenSDA Boards in Windows 8 and 10
Best Regards,
Robin
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------
Thanks, sadly my board fails the minimum firmware requirement for that procedure (apparently).
My board is 1.09
Paul S.
Paul
I also lost a FRDM-KL25Z but can't explain why its debugger died.
A general rule is to NEVER connect any such board to a Win 8.1...Win 10 PC with the reset button held down since it will cause the loaded debugger to be trashed (in fact I expect this to be the same with MAC and Linux since these do about the same as Win 8.1+ on connection [here is some info on what happens: http://www.utasker.com/kinetis/USB-MSD-MAC.html]
There is a method of configuring the way Windows behaves when a new external drive is connected (by changing repository settings) but it is tricky to find and I don't know whether it works the same on Win 10 - this allows new Win OS to be used to reprogram the debugger but it is best to have a Win 7 PC hanging around to recover if necessary.
Since I believe Linux will also trash the debugger it may explain why you couldn't reprogram it with Linux although it looked like it accepted the code.
I don't know why you had an issue with XP / Win 7 but a VM may not be adequate in this case.
I use this link as starting point to locate latest board debugger firmware: OpenSDA Serial and Debug Adapter | NXP
and have found that the Segger versions tend to be the best for newer boards. I avoid mbed and DAP since they often don't work correctly (debugger may work but USB-CDC doesn't etc. etc...).
Eric's blog is otherwise the standard work for recovery.
But if you don't get the boot loader any more I think the debugger chip needs to be reprogrammed (via SWD).
All boards have the possibility to mount a SWD header to program the development processor itself but without the debugger running you lose the VCOM connection to the UART, but this can be replaced by a VCOM connection from the KL25.
Regards
Mark
Hi Mark,
I'm organising a stand alone Windows 7 PC for all future firmware updating. But two questions for you:
1. Typically speaking, is it OK to update via a Windows 7 VM?
2. If I had a board that could be reprogrammed via the SWD header, what tool / adapter would I use for that process?
3. What about Linux for updating firmware, is that an option?
Thanks,
Paul Swanson
Paul
1. and 3. I can't answer since I use a dedicated Win 7 PC for recovery and not VM based. Also I don't use Linux.
2. I use P&E Multilink universal
As Eric noted above the older boards (the KL25 is old and most people start with a more modern processor like KL27 nowadays) are much more robust than the newer ones where essentially you immediately lose the debugger if connected to Win 10 with the reset held done. It can also happen when plugging in a board slowly to the USB socket (when the power supplied to it bounces form being applied, removed, applied removed, quickly). But I also lost a KL25 once without knowing why, but I never had problems with many other older boards even though I used them for hundreds of hours for developments.
I have almost all Freescale/NXP boards and from about the K22 they started to become a problem and since then I have the dedicated Win 7 machine exclusively for recovery, although don't use it that much any more as I am very careful and rarely use HW for product developments (see simulation below).
If you are starting out with Kinetis don't miss checking http://www.utasker.com/kinetis.html since it also allows Kinetis chip simulation (peripherals, interrupts, DMA, external devices) and so project development and [more more efficient] debugging without HW (good when you are waiting for a new development board to arrive or want to already complete final project firmware development before the final HW is ready). Apart from powerful libraries, integrated stacks, boot loaders and fast development you can then later move to other kinetis parts without needing to use different libraries and re-doing much of the project since it has only one driver that automatically adapts itself to all Kinetis parts. The same is true if you need more power in the future since the development can be moved to an i.MX with only a few defines changed (eg. https://www.youtube.com/watch?v=SmFTi8hlba0).
Regards
Mark
Just one comment about
>>But if you don't get the boot loader any more I think the debugger chip needs to be reprogrammed (via SWD).
This only is possible with the OpenSDA v2.x implementation/circuit (e.g. FRDM-K64F or FRDM-K22F, see How to Recover the OpenSDA V2.x Bootloader | MCU on Eclipse).
On earlier boards (FRDM-KL25Z and others) the K20 (debug chip for OpenSDA) is secured with FLASH Erase disabled (see How (not) to Secure my Microcontroller | MCU on Eclipse ), so it cannot be reprogrammed with the SWD header. The good thing about this is that the bootloader on these boards should not be affected by the Windows overwrite, but without updating the bootloader as described in Illustrated Step-by-Step Instructions: Updating the Freescale Freedom Board Firmware | MCU on Eclips... it still can affect the loaded debug firmware/application.
I hope this helps,
Erich
Thanks. This particular board is no longer showing any signs of life, but still worth knowing there's no SWD option.