frdm kl25z Opensda problem

[thiagomartins]

Looking to the annex image you can think that i dont have a problem. But i cant continue the debugg process of any program because of this message. If i click in "retry", this window close and open again. The problem is, as you can see, the computer is seeing the device.

I tried upload/debugg my program in de CW 10.3 in a Windows 7 and a CW 10.4 in a Windows XP. I also tried in 3 different boards with different cables, reseted the boards and changed the program, but the problem is always the same.

These 3 boards seem to have a problem, because when i use my friend`s freedom board, it worked.

After all, i think something has happened with my freedom boards, but i dont know what. One of them was new, the others 2 i have already soldered somethings.

I want my freedom boards back. anyone have any idea what might have happened or what i can do ?

[pgo]

Hi Thiago,

Your posting prompted me to re-visit the problem.  You may find this posting useful:

https://community.freescale.com/message/357906#357906

bye

[thiagomartins]

Hi,

I couldn't acess the link, "Unauthorized".

[BlackNight]

Hello,

Your screenshot tells me that your host PC is able to talk to the K20 OpenSDA on the board, but then fails.

The golden question is: what have you done?

In my view the problem is that the KL25Z on the board does not respond to the OpenSDA debug commands.

Can you enable logging (see “An error occurred…”: Applied Debugging Rules | MCU on Eclipse) and check the console output, maybe it gives a clue?

There can be multiple reasons why the KL25z does not respond any more:

- power: the board has a P_KL25Z jumper to disconnect power from the microcontroller. Are you sure it is powered?

- The RevE (see FRDM-KL25Z RevE Board arrived | MCU on Eclipse and Tutorial: Using the FRDM-KL25Z as Low Power Board | MCU on Eclipse) board has a jumper to disconnect the reset line between K20 OpenSDA and KL25Z: in that case the processor does not respond too.

- Are you playing with low power modes or have you disabled the reset line? In this case the KL25Z might not respond too. Then this post might rescue you: Bricking and Recovering FRDM-KL25Z Boards: Reset, SWD Clock and Low Power | MCU on Eclipse

I hope this helps,

Erich

[thiagomartins]

Hi Erich, thanks for answer me.

I've been until now testing a lot of things. And I have discovered that in my project had a disconfigured LCD component was using the PTA0 port. Moreover, the reset button was desabled and i didnt remember that. Now, after i fixed this problems, my project works. :smileygrin:

In this link mcuoneclipse.com/2013/06/16/bricking-and-recovering-frdm-kl25z-boards-reset-swd-clock-and-low-power/ was where i found the problem. But i didnt understand how to recover my freedom boards. Do I need a SWD external debug cable ? I tried use the P&E recovery utility, but i was not successful.

[BlackNight]

I had recovered most of my boards with an external programmer, so I needed to solder that SWD/Debug header for it. I was able to recover all my boards, except one where I enter low power mode with reset disabled too fast :-(. This is both a FRDM board issue (as pgo pointed out), but as well an ARM core issue as an external debugger can not keep the processor  in reset. So if the processor disables reset and enters low power right away, an external programmer has to be very fast to catch the small windows where it can talk to the microcontroller.

[pgo]

Hi Thiago,

I had a similar problem and concluded it was caused by either the SWD pins being disabled or the device entering low-power mode after reset.

I only reliable way I know of fixing this is to keep the chip in reset when it is being powered on.  A mass erase may then be done without releasing reset.  This will avoid the device disabling the pins or entering low-power mode.

This is not easily done with the FRDM boards since keeping the reset active also means that the board enters bootloader mode so you don't have a BDM!

If you have a revision E board you can open the  JP14 by cutting the track on the bottom of the board and then manually tie the reset pin low.  This allowed a USBDM programmer to erase the chip.  The firmware was used with the on-board interface.

An external programmer should also be able to erase the chip.  If you have two FRDM boards you could also use USBDM on one of the boards as an external programmer in this role.

IMO this is a design flaw with the earlier boards.

bye

[thiagomartins]

Hi,

Thanks for the reply. I have not had time to test yet. I am using another frdm for now because my project needs to be ready this week. Next week I will try to recover the boards and I come back to comment.

I'm sure that your and erich's comment will help me a lot. thanks again.

[hectorsanchez]

Make sure your Board is not in OpenSDA Bootloader mode first. It should be in OpenSDA Debug Application.

I recommend you checking this post on Erich Styger blog:

The Freescale OpenSDA Trap: “No Device Available”, or something like that…. | MCU on Eclipse