K60 Bare Metal

[ee]

I've built a custom board with a minimal K60 setup, in my first attempt to just boot up the chip.  However the chip never does boot, and I am at a loss why.

I power up with +3.3V, connect my P&E Micro Multilink Universal, CodeWarrior 10.2 bare metal project, and get this error message:

"Failed to resume target process., ARM GDI Protocol Adapter : Can't connect. The Debugger can not connect to the P&E device".

The project code I use in CodeWarrior 10.2 is a modified bare metal example and works on my stock TWR-K60 board, so I'm pretty sure my code and P&E pod is ok.

My custom board basically has a PK60FX512VLQ12 (0N96B), a JTAG connector, the three oscillators (50MHz, 12MHz crystal, 32.768KHz crystal), and a couple LEDs on GPIO lines to see if I'm alive.  I've copied the crystals and JTAG hardware setup from the TWR-K60F120M board schematics.  Am I missing something basic?  This thing should work, and I've checked the hardware over and over.  Perhaps fresh raw K60 chips need some sort of registers manually setup before they accept code?

The only life I see out of the K60 chip is every 44us the \RESET line (pin 74) pulses high 2us.  It does this whether the P&E is connected to the JTAG connector or not.  Does this indicate something?

Steve

Original Attachment has been moved to: 201305312034_DiagnosticInfo.zip

[ee · Accepted solution]

Today succeeded in getting my board to boot.  It required careful attention to the RESET_b signal pullup resistor and load capacitance values.  The RC time constant must be 10us.  My thinking was to attempt to stretch the width of the time the RESET_b signal was deasserted by the K60 by slowing the rise time with load capacitance.  I have found a 10K 1nF pair on RESET_b provides maximum width, and this is enough to allow the JTAG pods to connect.

With 10K pullup and no capacitance, when the K60 releases the open-drain RESET_b to float, RESET_b rises to 3.3V very quickly.  Somehow the K60 internally detects a rise above some voltage threshold, determines it is time to jump to vector zero, finds it to be invalid, and hard resets itself again.  The resulting time out of reset is 2us.  This is too short for inexpensive commercial JTAG pods to respond to.

With 10K pullup and 0.1uF capacitance as recommended by KQRUG, when the K60 releases the open-drain RESET_b, RESET_b rises to 3.3V very very slowly and the K60 resets itself before RESET_b even reaches 3.3V.  JTAG pods never recognize the K60 getting out of reset and so cannot connect.  [The TWR-K60 has 0.1uF capacitance on RESET_b, but doesn't have a pullup resistor at all -- maybe the on-board OSBDM works ok under these conditions and has a stiffer internal pullup -- I do not have time to investigate this.]

With 10K pullup and 1nF capacitance, when the K60 releases the open-drain RESET_b, RESET_b rises to 3.3V slowly enough to stretch the time the K60 is out of reset from 2us to 10us, while also allowing RESET_b to reach 3.3V.  This appears to be just enough for commercial JTAG pods to respond and connect.

In the end, no pullups on any of the EXP_ signals are needed.  The only issue is RESET_b -- it requires a 10K pullup to +3.3V, and a 1nF capacitor to GND.  The exact values do not matter, but the RC time constant must be approximately 10us.

Steve

[LuisCasado]

Hello,

A couple of things:

1) Check that you are not in eZPort mode, EZP_CS line

2) Try a mass erase with CW Flash Programmer first.

Luis

[ee]

Luis:

Thanks for these suggestions!

1) I have left EZP_CS floating, as it is floating (actually only connected to a touch pad but same thing) on the TWR-K60 board (default with R72 as DNP).  I will try a formal pullup to 3.3V, but I did already probe EZP_CS with a scope while applying RESET low, and it appears to be pulled high already internally.  I will double check this.

2) I cannot seem to mass erase if I cannot connect.  If I use the CW flash programmer, it gives the same "can't connect" message dialog.  Luis, If you can point me to the steps involved to mass erase I would like to try exactly what you had in mind.

This week I will order a Segger J-Link, as one other forum thread pointed to using a j-link vrs a multilink as a solution.

Steve

[ee]

Today I soldered in a 4.7K pullup resistor from EZP_CS line (pin 54) to +3.3V.

No change observed.  Still same "can't connect" error message.

Also same curious behavior where the K60 chip repeatedly drives its own RESET line low for 42us, allows it to be pulled high for 2us, then drives it hard low again.  The k60 is definitely alive - perhaps just stuck in some sort of watchdog loop that must be disabled first before initial programming can begin.  I need some help on this.

Steve

[LuisCasado]

Hi

regarding point 2, you can create a New project for your device with Wizard and go to Flash Programmer, then Flash File to target and Erase Whole Device. Select the connection for the new project created.

Best Regards,

Luis

[ee]

Thanks - no that doesn't work.  "Erase Whole Device" starts the script but I still get "can't connect" dialog.

It looks like I can force EZP mode by holding EZP_CS low during reset-- this stops the 44us watchdog loop.  Would be nice to have EZP tools available to try and mass erase that way but I don't yet.

I'm curious what method Freescale uses to bring up their K60 tower card the first time.

Steve