[SOLVED] Connecting/programming issues NXP (Freescale) MK60DN512VLQ10 (older MCU revisions 4N30D, 8N30D)

HansKinetis · Dec 15th 2017, 11:58am

I am having issues with programming NXP (Freescale) MK60DN512VLQ10 microcontrollers using the SEGGER J-Link Plus. Connecting to the microcontroller with J-Flash succeeds most times without errors, but programming its internal flash memory fails most times. I wonder if this could be caused by trying to program older microcontroller device revisions, 4N30D, 8N30D, etc. and that J-Flash can only program more recent devices (like 4N22D, 5N22D). J-Flash doesn’t let you choose among different device revisions when selecting an MCU.

The electrical connections seem to influence the success rate, but I am not certain about which connection between J-Link and the MCU device could be wrong. The only issue I have been able to resolve is the state of the RESET signal: it should not be pulled down; the J-Link status LED will change from green to red otherwise, and programming is impossible. Signals nTRST, TCK, TDI, TDO, TMS all have pull-up resistors to VTref (2.5 V), signal RTCK is connected to ground and signal DBGRQ is left open. Signal shapes of TDI, TCK look good, but some MCU devices do not send data out on TDO.

If have also noticed that the RESET line can be pulled down by the MCU device itself: it seems that the MCU can reset itself periodically. This may be caused by an active watchdog in an unprogrammed device.

Sometimes the “unlock kinetis” command (using J-Link commander) seems to help.

When connecting to a device, error messages “Could not find core in Coresight setup” or “InitTarget(): PCode returned with error code -1” are shown. When trying to program and verify a device, error message “JTAG Connect (1000 kHz, Core ID: 0x4BA00477) OK; Verification of RAMCode failed @ address 0x1FFF0000. Write: 0xA801BE00 F0009900 Read: 0x00000000 00000000. Failed to download RAMCode!” appears.

Does anyone recognize these programming-related problems? Has anyone been able to resolve these?

Kind regards,

Hans

SEGGER - Nino · Dec 15th 2017, 1:30pm

Hello Hans,

Thank you for your inquiry.
Such an issue is not known to us.
The MCU revision should make no difference as we even have some pre production samples from Freescale here that work without any issues.
Are you using an eval board or custom hardware?
If custom hardware, is the issue reproducible on an eval board?

The electrical connections seem to influence the success rate, but I am not certain about which connection between J-Link and the MCU device could be wrong.

You write VTref is only 2.5V. Generally the MCU is a 3.3V device. So check your power supply if enough power is delivered.
During flash programming an MCU usually draws the most current. Check if the supply voltage drops even further when initiating a flash download.
If it drops then your power delivery is not sufficient and thus flash programming fails.

Sometimes the “unlock kinetis” command (using J-Link commander) seems to help.

This should only help if you programmed the lock bits of your device.

Best regards,
Nino

HansKinetis · Dec 15th 2017, 4:30pm

Hello Nino,

Thank you for your quick reply and for your confirmation concerning older MCU revisions.

We do have an evaluation board (but not an MCU evaluation board) on which this MCU is present, together with a JTAG interface connector. It directly connects to our J-Link Plus, and connecting/reading this MCU is no problem. (We don't try to erase/reprogram this particular MCU, because we can't afford to loose our evaluation board.)

Both MCUs on the evaluation board and on our own custom board run at 2.5 Volts. This power supply voltage is (according to NXP) well within specifications - even for flash programming - but I will check that soon. No, the problem occurs even before flash memory is being programmed: loading RAMCode (into RAM, not flash) often fails too. Memory reading (using J-Mem) also seems to function inconsistently.

Yes, unlocking a device when it is not locked in the first place doesn't make sense. Unfortunately the "unlock" command does't tell the user whether the device was locked at all when it reports that it has successfully unlocked the device...

Best regards,

Hans

SEGGER - Nino · Dec 18th 2017, 10:32am

Hi Hans,

What J-Link software version are you using for your setup?
I tried to reproduce the issue with V6.22d a J-Link Plus and TWR-K60N512 eval board.
VTref is 3.3 V and everything is working as intended.

It directly connects to our J-Link Plus, and connecting/reading this MCU is no problem. (We don't try to erase/reprogram this particular MCU, because we can't afford to loose our evaluation board.)

We generally recommend to test everything on an eval board first and then transfer that knowledge to the custom board.
Why do you think you would loose your board when reprogramming it?
If you choose the non (allow security) device in J-Flash then nothing can go wrong as J-Link does all checks and asks you before you would do something bad or irreversible to the chip.

Both MCUs on the evaluation board and on our own custom board run at 2.5 Volts. This power supply voltage is (according to NXP) well within specifications - even for flash programming - but I will check that soon.

According to the data sheet of the K60 2.5 V are in the range of "Falling low-voltage detect threshold — high range" which is below all "Low-voltage warning thresholds — high range"
so I assume that in that modes the MCU is limited in some functionality. Unfortunately the data sheet does not tell in what way but it is possible that it is affecting memory writes of any kind.

Generally we recommend testing everything with recommended power supply setups and test low power modes when a stable setup has been achieved with the recommended setup.
For more information about the target device try to get into contact with NXP.

Best regards,
Nino

Share