Over a million developers have joined DZone.

Disabling EzPort on NXP Kinetis to Solve Power-On Issues

DZone's Guide to

Disabling EzPort on NXP Kinetis to Solve Power-On Issues

The NXP Kinetis' EzPort can be used to program the device, but if it's hooked up to a battery, it might cause startup issues. Here's how to get around them.

· IoT Zone ·
Free Resource

I’m using the NXP FRDM-K64F board in several projects: It is reasonably priced, has USB, Ethernet, a micro SD card socket, and connectors for Bluetooth classic and a Nordic Semiconductor nRF24L01+ 2.4 GHz transceiver:



But one issue I have faced several times is that the board works fine while debugging and connected and powered by a host machine, but does not start up sometimes if powered by a battery or started without a debugger attached. I have found that the EzPort on the microcontroller is causing startup issues.

The EzPort is a special serial interface present on some NXP/Freescale Kinetis (e.g. K64F), ColdFire+ and ColdFire V2 devices. Through that port, I could program the device with an SPI compatible interface: One use case is to use it instead of the normal debug interface to program the microcontroller e.g. from another microcontroller (see this link). I have not used EzPort for my projects, but I have found that this feature can cause issues if not handled properly.

The issue is that if the EzPort chip selected (EZP_CS) is LOW during a reset of the microcontroller, it enters the special EzPort mode. The problem is that a pull-up on the EZP_CS line might not pulled up fast enough due capacitance on the line:

Image title

The yellow signal is the reset line, and the purple one is the EZP_CS: It does not rise fast enough, therefore the microcontroller will enter the special EzPort mode while powering on.

As with anything else: If something is not used, disable it! So the solution is to disable the EzPort functionality. That setting is part of the FOPT (flash option register).


EZPORT_DIS in FOPT (Source: Kinetis K64F Reference Manual)

With Processor Expert projects there is a setting for this in the CPU component properties (EzPort operation at boot):

Disabled EzPort with Processor Expert

Disabled EzPort with Processor Expert

This configures the NV_FOPT register:

 /* NV_BACKKEY3: KEY=0xFF */ \
 0xFFU, \
 /* NV_BACKKEY2: KEY=0xFF */ \
 0xFFU, \
 /* NV_BACKKEY1: KEY=0xFF */ \
 0xFFU, \
 /* NV_BACKKEY0: KEY=0xFF */ \
 0xFFU, \
 /* NV_BACKKEY7: KEY=0xFF */ \
 0xFFU, \
 /* NV_BACKKEY6: KEY=0xFF */ \
 0xFFU, \
 /* NV_BACKKEY5: KEY=0xFF */ \
 0xFFU, \
 /* NV_BACKKEY4: KEY=0xFF */ \
 0xFFU, \
 /* NV_FPROT3: PROT=0xFF */ \
 0xFFU, \
 /* NV_FPROT2: PROT=0xFF */ \
 0xFFU, \
 /* NV_FPROT1: PROT=0xFF */ \
 0xFFU, \
 /* NV_FPROT0: PROT=0xFF */ \
 0xFFU, \
 0x7EU, \
 /* NV_FOPT: ??=1,??=1,??=1,??=1,??=1,??=1,EZPORT_DIS=0,LPBOOT=1 */ \
 0xFDU, \
 /* NV_FEPROT: EPROT=0xFF */ \
 0xFFU, \
 /* NV_FDPROT: DPROT=0xFF */ \
__attribute__ ((section (".cfmconfig"))) const uint8_t _cfm[0x10] = {CPU_FLASH_CONFIG_FIELD};

If using the Kinetis SDK, look for something like this (usually in startup*.S):

/* Flash Configuration */
 .section .FlashConfig, "a"
 .long 0xFFFFFFFF
 .long 0xFFFFFFFF
 .long 0xFFFFFFFF
 .long 0xFFFFFD7E


Usual projects have the EzPort enabled. This can cause issues with the power-on sequence of the microcontroller: if the EzPort chip select pin is low during reset, the processor will enter the EzPort mode, and this might not be what is intended. The solution is to disable to set the EZPORT_DIS bit in the flash configuration register.

Happy EzPorting!


iot ,tutorial ,nxp kinetis ,ezport

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}