Dear fellow members,
I would like to approach you with the problem related to programming or code download into Kinetis K60 throught the OSBDM JTAG interface. Last year in December we've created at our university (Brno University of Technology, Faculty of Information Technology, Brno, Czech Republic) prototype of educational kit for our students where 6pcs were available. These boards (see schematics in the attachment) were assembled with following Kinetis K60 types:
1) MK60DN512ZVMD10, mask 4N30D, batch CTCTAW1236X
2) MK60DN512ZVMD10, mask 4N30D, batch CTCTAU1234B
In case of option 1) the board worked without any problems at all but we have experienced difficulties (it wasn't possible to download any piece of code through CW 10.3 and OSBDM interface with firmware version 31.21) with option 2) used on 5 of the boards presumably due to faulty components. After removal and replacement of these 5pcs boards started to function as expected even if components with the same identification as in 2) were used.
Yesterday, we have received first 20pcs from the main production batch which should include some 550pcs but the problem with JTAG programming appeared again on all of these boards. Following component was used:
MK60DN512VMD10, mask 4ND22D, batch CTCTAA1249A
I suspect that complete delivery of these 20pcs of Kinetis MCU could be faulty as the rest of our board (with the same circuit schematics as on the prototypes) works without any problems. Would you have any suggestion how to solve this problem? Or perhaps the difficulties mentioned above may have occured due to some soldering problem, I really do not have any clue in this case.
With kind regards,
Vaclav Simek
Solved! Go to Solution.
Hello,
The whole issue was successfully resolved at last with help of few
colleagues from Freescale branch office in Roznov, Czech Republic.
Probably the only source of our problems was identified in missing
pull-up resistor on PTA4 pin of K60 MCU which now blocks the
activation of EZP debug port if the JTAG interface usage is preferred
instead. In case this particular pull-up resistor is omitted, EZP is
activated which, of course, results in wrong information being send to
Code Warrior over JTAG wires.
It seems like the necessary pull-up would be eliminated from later MCU
die mask revisions, as described in my initial post on Freescale
community web site and also in support system. It's interesting to
note that we've made 6pcs of prototypes with the same schematics and
PCB yout which weren't showing any functional problems, unlike the
pilot batch of 20pcs with updated version of K60 chip. So the
conclusion is that the pull-up resistor MUST be included on PTA4 pin!
With kind regards,
Vaclav Simek
Hi,
I check you submit the same issue to our sevice system with SR: 1-1066050120.
If your issue had been resolved?
If you have any updated issue, please let us know. Thanks for the attention.
Hello,
The whole issue was successfully resolved at last with help of few
colleagues from Freescale branch office in Roznov, Czech Republic.
Probably the only source of our problems was identified in missing
pull-up resistor on PTA4 pin of K60 MCU which now blocks the
activation of EZP debug port if the JTAG interface usage is preferred
instead. In case this particular pull-up resistor is omitted, EZP is
activated which, of course, results in wrong information being send to
Code Warrior over JTAG wires.
It seems like the necessary pull-up would be eliminated from later MCU
die mask revisions, as described in my initial post on Freescale
community web site and also in support system. It's interesting to
note that we've made 6pcs of prototypes with the same schematics and
PCB yout which weren't showing any functional problems, unlike the
pilot batch of 20pcs with updated version of K60 chip. So the
conclusion is that the pull-up resistor MUST be included on PTA4 pin!
With kind regards,
Vaclav Simek