Hello,
I asked for soldering an MK20128VFT5 uC in my custom board.
I have already tried to program with olimex arm-usb-ocd-h with open ocd, and Segger j-link with J-Link commander using JTAG.
Connections:
Target | Programmer |
Tref | 3.3V |
GND | GND |
TCK | TCK |
TDO | TDO |
TDI | TDI |
mRESET | GND |
Just connecting mRESET directly to ground I have something "working", otherwise I din't have anything working I think because of protected kinetis.
Using open Olimex programmer, openocd reported to me that I'm using MK10DX8xxx5. Should be an MK20, so I'm also concerning the chip that the fabric soldered in my board (Reference in the chip M20AGV 3N86B 4EJYA).
With Segger J-link, when I try to unlock kinetis, I have the error described in the attachment (tmp.png).
Some relevant information about MDM_AP (tmp2.png).
I really appreciate your help.
Thank you in advance.
Fábio Vasconcelos
It was already solved.
While debugging the pcb board, we get that that is a ground pin unconnected.
Then we tried to program the uC with Olimex ARM-USB-OCD-H but stills protected.
Rather than, we connect RST of uC to GND, and start sending kx.cfg commands 1 by 1 till the uC stayed it is unprotected, then we connect RST of uC to JRST of JTAG and continue sending the .kx.cfg commands. It works!
Have you tried talking to the chip with the SWD instead of JTAG?
And as noted: the Reset line shall be pulled high, not tied to GND.
Not yet, but I will give a try and let you know
Hi;
Have you tried selecting the device "MK20DX128XXX5 (Allow Security)" instead?
Reset_b should be pulled high regardless - maybe try pulling it to VDD through a 10k resistor.
Kind regards,
Troels
Thinking a bit more about this.
The Segger J-link has a dedicated nRESET pin, which should connect to RESET_b on the MCU, but it is still recommented to pull it up by a resistor on the board, so that it doesn't float.
Also, follow the recommendations here:
https://www.segger.com/products/debug-probes/j-link/technology/interface-description/
E.g., use pull-ups on TDI, TMS, TRST.. maybe TCK as well.
When it is a new MCU, it should not be locked in any way, which is very strange.
I already flash some firmwares in this MCU, exactly the way you described, but all of them are already flashed previously in de PCB supplier.
However, this time the MCUs arrived cleared and I face this problem exactly with the connection you suggest (tmp4.png)
I searched in internet about it and it seems they are protected and some people solved their problems connecting RESET_b on the MCU directly to ground and performing a unlock kinetis and it works fine.
Connecting to ground at least I can connect, but failed when I try to unlock it.
Thank you so much for your time
If you don't have a valid program on the device, then it will constantly reset: it will start running, then run into an illegal instruction, reset again, and so on. So this his normal.
The debug probe needs to get hold of the device first and program it with a proper binary.
I already have a working firmware, my problem seems that the MK20 is protected and I'm not finding a way to unlock it to flash there a bootloader and a firmware.
Thank you so much for your time