Can not connect to MK64FX512 via J-link debug probe

[rumenpasev]

Hello, I have a problem trying to connect to MK64DX512 MCU on a newly developed board via J-link debug probe.

I could not connect both using JTAG and SWD.

I already have experience with various KINETIS devices, including one from the same 'K' series - MK40DX64VLH7 with several boards designed and performing well with this MCU.

So the hardware used for connection to the MK64DX512 MCU is tested and working. Additionally, on the same new board where MK64DX512 is mounted, there is another small KINETIS MCU - MKV30F64 and I can communicate with it over SWD.

Of course, the cause for the problem should be in the new board.

My co-worker who designed the board, looked carefully for any possible discrepancy with grounding and power supply wiring but couldn't find anything disturbing.

So, I need some hint to come out of the situation.

I apply some log from the J-link sessions, but before browsing them, here’s some more information:

•      The problem occurred on two different boards, but one of them behaved much better at the beginning – the J-link not only connected to the SW-DP, but had partial success in connecting to the CPU core. However, shortly after that this “better” board started behaving exactly the same as the other one.
•      As you can see from the logs, J-link finds that the flash protection bit is set, which is not realistic for a new device, probably there’s a problem with reading the flash configuration area

First, this is how attempts to connect look now:

SEGGER J-Link Commander V6.48b (Compiled Aug  2 2019 10:19:19)

DLL version V6.48b, compiled Aug  2 2019 10:18:25

Connecting to J-Link via USB...O.K.

Firmware: J-Link V9 compiled May 17 2019 09:50:41

Hardware version: V9.30

S/N: 269307064

License(s): FlashBP, GDB

OEM: SEGGER-EDU

VTref=3.366V

Type "connect" to establish a target connection, '?' for help

J-Link>connect

Please specify device / core. <Default>: MK64FX512XXX12

Type '?' for selection dialog

Device>

Please specify target interface:

1. J) JTAG (Default)
2. S) SWD
3. T) cJTAG

TIF>s

Specify target interface speed [kHz]. <Default>: 4000 kHz

Speed>

Device "MK64FX512XXX12" selected.

Connecting to target via SWD

InitTarget()

Connect Under Reset

Device will be unsecured now.

Found SW-DP with ID 0x2BA01477

InitTarget()

Connect Under Reset

Protection bytes in flash at addr. 0x400 - 0x40F indicate that readout protection is set.

For debugger connection the device needs to be unsecured.

Note: Unsecuring will trigger a mass erase of the internal flash.

Executing default behavior previously saved in the registry.

Device will be unsecured now.

Found SW-DP with ID 0x2BA01477

****** Error: DAP error while reading DP-Ctrl-Stat register.

InitTarget()

Connect Under Reset

Protection bytes in flash at addr. 0x400 - 0x40F indicate that readout protection is set.

For debugger connection the device needs to be unsecured.

Note: Unsecuring will trigger a mass erase of the internal flash.

Executing default behavior previously saved in the registry.

Device will be unsecured now.

Found SW-DP with ID 0x2BA01477

InitTarget()

Connect Under Reset

Protection bytes in flash at addr. 0x400 - 0x40F indicate that readout protection is set.

For debugger connection the device needs to be unsecured.

Note: Unsecuring will trigger a mass erase of the internal flash.

Executing default behavior previously saved in the registry.

Device will be unsecured now.

Found SW-DP with ID 0x2BA01477

Cannot connect to target.

J-Link>

And then, the stored logs from the 'better' board before it deteriotated.

These logs were saved as screenshots, I can't reproduce them any more and paste them here, so they are in the file attached.

(During all this struggle I updated J-link firmware and J-link PC-software, so the logs look a bit differently

for the same board with the same behavior.)

Thank you in advance for any hints and suggestions we might give me so that I can figure out what causes the problem 

[FelipeGarcia]

Hello Rumen,

It seems that J-Link will is trying to disable the protection on connect.

However this will only work if the reset line is connected from J-Link to target interface.

Is this the case with your hardware? If the reset pin is connected correctly you should get a successful connect.

In addition, I recommend you to check the schematics of our FRDM-K64F development board and see if there are any differences visible.

https://www.nxp.com/webapp/Download?colCode=FRDM-K64F-SCH-C

I hope this helps.

Have a great day,
Felipe

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

[rumenpasev]

Hello Felipe,

Thank you for the swift reply.

Thank you also for the link to the FRDM-K64F board schematics, in fact I've already looked at them, but it never harms to have a second scrutiny, especially if nothing else helps.

Regarding your question:  I'm aware of the importance of the reset line, as I already met such a problem with another Kinetis MCU after securing the device, and then J-link was only able to reprogram its security bits after we connected the reset pin. But this is not the case with the present hardware, as the reset connection between MK64 and J-link is in place both for the JTAG and the SWD interfaces.

And it's also strange that J-link tries to unsecure the device, as its shipping condition should be 'unsecure' as for all Kinetis MCU-s.

Further on, in most connection sessions the only 'normal' message from J-link had been 'Found SW-DP with ID 0x2BA01477', but as seen from the screenshots in the file I included, for a short while J-link also produced more normal reports (exactly the same as the ones when connecting to MK40DX with which I have had no problems) such as:

'AP[0]: AHB-AP (IDR: 0x24770011)

AP[1]: JTAG-AP (IDR: 0x001C0000)'

'Implementer code: 0x41 (ARM)'

'Core found'

These messages were present at the beginning, and then permanently disappeared. Suspecting an MCU damage in some way, we replaced the device but nothing changed.

Having insufficient understanding of the whole process of communication between the Debug Port and the MCU Core, I'll better state some questions in other way:

- How could it happen, that J-link connects to the Debug Port, but cannot further connect to the Core? Could it be due to some MCU damage or due to some flaws in J-link scripts for the specific MCU? How initial presence of lots of 'normal'

J-link reports and their disappearace later on could be explained?

- Is there some substantial difference between MK40DX and MK64FX MCUs with regard to their debug port connectivity (I thought they're identical)?

I made some search in the Segger Forum, so far I found a case of problem with JFlash and MK64F that has occurred some time ago, but it's been tagged as 'solved'.

So, unfortunately, the problem persists, I'll go on searching for its cause and any useful info or suggestions from you will be of help.

Have a nice day,

Rumen

[FelipeGarcia]

Hello Rumen,

Could you please double check that you are not changing the Flash Configuration Field Descriptor? The program flash memory contains a 16-byte flash configuration field starting at 0x0400.

Also, when accessing this part of flash please select the "allow security" target device in the J-Link commander.

Regarding your questions:

 - It could be that your MCU is damage due to hardware issues. I recommend you to do the swap test by changing the MCU and try it with a different board and see if it the MCU is damaged or the board has hardware issues.

 - MK40DX and MK64FX debug architecture are the same as both are Cortex-M4.

Best regards,

Felipe

[rumenpasev]

Hi again Felipe,

finally it turned out that the cause of the problem had been a very silly one - the NMI / EZP_CS pin being assigned as PWM output, had been connected to a transistor base circuit and in fact given a logic ‘0’.

Sorry for bothering you and thanks for the assistance.

Best regards.

Rumen

[rumenpasev]

Hello Felipe,

Thanks for the reply.

As regards changing anything within the flash configuration field – I haven’t had the chance of doing so as I can’t even read the flash without establishing a connection with the MCU.

A hardware damage of the MCU was our first assumption, so we tried two different boards, and then replaced the MCU on one of them.

Now, I’m preparing to try a connection using a less intelligent but more versatile debug probe. I’ll probably write later when I have some results.

Have a nice day,

Rumen