I’m working with a student on building a small autonomous robot platform, based on the FRDM-KL25Z board. We integrated new software modules, compiled and linked, and then downloaded the application to the board. While debugging and stepping through the application startup, I had this:
Outsch! That’s not good. Even worse, trying to connect again to the board failed :-(. What happened?
An Error Occurred…
My connection settings were still fine, and the OpenSDA properly recognized. Still it continued to report that an error occurred while connecting to the hardware:
Ok, I definitely have a problem to regain access to my FRDM-KL25Z. The board is ‘bricked‘ 😦 and I probably will not be useable any more.
We did before hardware changes, so it could be the problem? So maybe that hardware change could have had an impact? Removed that hardware, but still not able to connect to the board. Head scratching…..
Maybe that hardware could have damaged the board? This because we determined that this hardware wiring was not correct neither. Maybe it was drawing too much current and destroyed some parts on the board? Visual inspection did not show anything, and the OpenSDA LED was still working properly.
Ok, so let’s try with a brand new board from the inventory. Changed the OpenSDA firmware from MSD bootloader to the debug application, downloading the program and …..
Aaaaaaahhhhhhrrrrrggg! Again lost connection :-(. Same thing. Able to download, then did a run, and then the debugger lost connection to the board. After that: not able to talk to the board again. 😦
Now this now a real issue, so slowly trying again with yet another board, carefully exploring what is causing this problem.
Well, you can imagine how this ended up: after a very short time, I had 6 bricked boards on my desk, and my board inventory depleted rapidly 😦
Trying different probes to recover
Desperately, I tried many options to recover my boards:
- As USBDM was able to recover my board in a single case, I tried USBDM OpenSDA: Failure :-(.
- Then my hopes are with using the RedLink OpenSDA: failed too 😦
- Segger OpenSDA: no success 😦
- Using IAR workbench with CMSIS-DAP: nope 😦
- Soldered the 10pin ARM Cortex debug header and tried with the P&E Multilink Universal (green unit) and FX (black unit): still no success 😦
- Trying to reset the board, re-powering with the debugger attached, doing random access methods: all failed 😦
Hunt for the Cause
Ok, whatever I tried, but just getting me deeper into the mud. From my previous experience, it is possible to brick a board with securing it with FLASH bits disabled. Carefully checking the not so small application, and this confirmed that the FLASH security bits are *not* set. So this could not be the problem.
Further, I had another board bricked a couple of weeks ago, where I was entering low power mode, and somehow the board was not recovering again. That board always had the blue RGB LED on indicating low power mode. Carefully checking the application if it does enter low power mode, and as expected, this was *not* the case. So this again could not be the problem.
Running out of ideas, I contacted the folks at P&E, because I thought that might be something other users might meet, and they would know best why their (and others) run control devices is not able to talk to the KL25Z on the board. They immediately returned my inquiry, and they were able to reproduce it with my application. So far so good (or bad). Now the joint hunt for the cause started.
Edison from P&E pointed out that I use the FOPT register at address 0x40D in my application to disable the RESET pin of the processor. Yes, I do this on purpose (see this post), because the FRDM-KL25Z board does not have a user button. But I do this for my other projects too, and have not seen an issue with it? That should not be the problem, at least alone?
The other suggestion was about low power mode, but as above: low power mode is not used.
Then Edison provided the correct tip: The FRDM-KL25Z uses the ARM SWD (Single Wire Debug) interface. Edison pointed out that if PTA0 (SWD_CLK) or PTA3 (SWD_DIO) are re-assigned as GPIO pins, that could explain the symptoms. Head scratching….. While that would be indeed a problem, I’m not aware that this would be the case.
To be sure, I checked every settings of the Processor Expert components used in the project. And after a while I saw this:
That project has added component for SMAC/IEEE802.15.4. The SMAC is using an external interrupt pin from the radio transceiver. When added that component to the project, Processor Expert has assigned just a default pin. Which unfortunately was the pin for SWD_CLK :-(. Not good. Really not good.
So this really could be the cause of the problem. Changing that interrupt pin to the correct pin (while still having reset disabled), trying it with a new board (pleeeeeaaase, pretty please, do not loose connection!): YES, I do not lose connection, and my board behaves fine! Ufff!!!!! 🙂
Unbricking the Boards
With the problem found, we were able to continue the project without risking a huge pile of bricked boards. But how to recover the bricked ones.
With now the problem known, P&E provided me a recovery tool. That tool basically tries to get access to the microcontroller during its reset sequence. For this it runs in a loop and tries to stop the processor as often as possible. So while running that recovery tool, I need to power-on the FRDM-KL25Z. Depending on the timing, there is a chance that the utility catches a window to halt the processor fast enough. It might not work the first time, but chances are good that after a few times I can hit that window.
P&E Recovery Utility
P&E has published that utility (you need to register) on their website (link below). It requires an external probe like the P&E Multilink (OpenSDA did not work for me). Consequently, the 10pin ARM JTAG header needs to be populated on the board:
Here is how to use the utility to recover a board:
- Download P&E recovery utility which comes in a .zip archive.
- Unzip the archive to the hard disk
- Run the Kinetis_Recovery_Utility.exe:
- Select the Multilink as connection with communication set to ‘SWD’
- Then press the ‘START’ button
- Then unplug-replug (re-power) the board, until there is a ‘Success. Processor halted’ message.
- Close the P&E recovery utility (keep the board powered and in halted mode!).
- Use the CodeWarrior debugger with the P&E Multilink connection to program/erase the board.
💡 I tried to use the OpenSDA (instead of the Multilink) to program the board after it has been halted. But this did not work for me. Using the Multilink was working, so if you have your connection set up to use OpenSDA, temporarily change it to use the Multilink instead.
I needed up to 50 to 60 attempts to get the processor halted.Carefully watch the recovery window.
💡 Instead of using the USB cable to re-power the board, I used as well the power jumper on the FRDM board (P_KL25z), and this worked too.
That way I was able to recover 6 boards. But not this one:
The program on this board disables the reset button, configures wrongly the SWD clock pin and turns the RED RGB LED on. This application is the result me trying to reduce the problem. But by reducing the problem, the board performs the disable-reset-button-and-misconfigure-SWD-clock so soon after reset, that it was not possible with the P&E utility to recover that board.
Blue LED of Low Power
On the positive side: I had another board ‘bricked’ just by the fact that I was using one of the low power modes. I used the blue RGB LED to show that the board is in low power mode: While experimenting with the modes, I ended up that the board was not accessible any more by the debugger: after entering the low power mode, the board disabled the SWD debug block.
The good news is: with the same recovery tool, I was able to regain that board too :-).
In case reset is disabled early in the startup of the processor, then the debug probe might not have enough time to halt the processor running out of reset. If this is combined with wrong code disconnecting the SWD clock or other debugging pins, then things are really going bad. I learned that
- Carefully check the interrupt vector assigned by Processor Expert, and make sure no ‘vital’ line is used. Especially SWD_CLK or SWD_DIO.
- Be careful with any pin muxing of pins.
- If testing or implementing low power modes, make sure that low power mode is entered after some time after startup if possible, to give the debugger a chance to halt the processor. Carefully plan the low power strategy from the low power mode (e.g. having a dedicated wake-up reset).
- Do not disabling the reset pin. Or of so, do it very late in the startup, or even better after a delay of a few seconds. That way a run control device has a chance to reset the processor after power-on.
- Have a few spare 10pin ARM Cortex debug headers availble to populate the SWD connector on the board.
- Always have a SWD external debug cable (P&E Multilink) available.
I hope Freescale considers adding a normal push button to their Freedom Boards so users are not tempted to re-assign the reset button as a general purpose button. That’s where things started to get ugly for me. The SWD_CLK in combination with disabling the reset line was bricking my boards, and I would not have disable reset if the FRDM-KL25Z would have a normal user push button ;-).
And: I want to thank you the support folks at P&E Microcomputer Systems and especially Edison for helping me with this issue and providing that recovery tool.
Happy Unbricking 🙂