FRDM-K64F booting issue when powered from USB port

[hamimonsarrat-c]

I am facing an issue when powering the FRDM-K64F board from its USB port.

If I leave the board without power for more than 10 seconds, the card would never boot

powered from the port. I have to disconnect it and reconnect it within that 10 seconds period.

The problem can lead to different symptoms depending on the host.

I originally worked on this in the mbed community context. More details about the issue can be found

in the following post: USBDevice on FRDM-K64F sometimes crash my laptop - Question | mbed

In my USB device application, that powering issue is a serious blocker.

Any help would be appreciate.

Since we are basing the development of our custom board on the FRDM-K64F schematic,

we need to solve this before going forward.

Sincerely,

[loicguillain]

Hello all,

I have a problem with NMI too.

I connect this USB_DETECT to the GPIO used for NMI too x_x

When I boot my program by USB it works but if i disconnect USB to be powered by the battery I connected it falls in DEBUG_HALT (when NMI is not selected in configuration) or NMI_Interrupt (when I create it)

I would like not to fall in this interrupts. Someone has an idea?

Thanks to you :smileyhappy:

[mjbcswitzerland]

Hi

How to start executing program on K64F right after power on

Regards

Mark

Kinetis: http://www.utasker.com/kinetis.html

K64: http://www.utasker.com/kinetis/FRDM-K64F.html / http://www.utasker.com/kinetis/TWR-K64F120M.html / http://www.utasker.com/kinetis/TWR-K65F180M.html

For the complete "out-of-the-box" Kinetis experience and faster time to market

[loicguillain]

Thanks but I already desactivated NMI and EzPort, I even init a GPIO on this pin in OUTPUT and change the pin function in the Pins component but nothing to do ...

[loicguillain]

My new problem is: I disconnect USB (so the USB Detect pin on the NMI too) during my program is running: it works very well but if I click on my reset button when it's battery powered (without USB then) it falls in HALT_DEBUG and to go out of the routine I have to connect my USB back and re-click on the reset button...

[loicguillain]

According to the datasheet the 3 last bits of FOPT register are important for us: NMI_DIS / EZP_DIS / LPBoot.

But when I generate code NMI_DIS appears as a "??=1" so I observe if that bit changed and guess what? Nope... I have to change it in the code ( to have 1111|1001 --> 0xF9 ) each time I generate code with PEx :smileysad:

Now I can reboot normally without USB supply but with battery supply (using that NMI pin as a normal GPIO)

[hamimonsarrat-c]

Doing additional tests, I noticed that pushing the reset button with J25 bypassing the U3 OpenSDA reset does boot the MCU.

I am also adding that my FRDM-K64F boards are rev D1. (700-28163 REV B, SCH-28163 REV D)

[tsi-chung_liew]

Hi,

The PTA4 (NMI) is let float and tie to gnd with a small capacitor, the chances are going to NMI is 50%. Either you need a 10K resistor populated in R75 (next to tri-color LED) or implement the NMI interrupt service routine in software.

Regards,

TsiChung

[hamimonsarrat-c]

Hi,

I had no 10k resistor in my pocket easy enough to solder on the R75 footprint but had a 2.2k and and 22k.

I tested both and got the same result: the CPU never boot, all the time when I connect the K64F USB port.

This was half-good, since it told me that my problem is most likely related to the NMI, as you stated.

I then emptied R75 and also removed  the C55 capacitor. It fixed it. My test card now boots 100% of the time when I connect its K64F USB port.

(with a default mbed firmware running)

Any idea why the 2.2k or a 22k would not fix the problem?

When I'll get my hand on a usable 10k, I'll see if I replicate my observations.

I'll also check what can be done on the software side.

Maybe my observation are related to mbed boot sequence in some way..

I'll communicate with the mbed experts and see what they think of this.

[tsi-chung_liew]

Hi,

There is internal pull-up on NMI pin, place the C55 capacitor will act as pull down and affect the ramp of the signal as well. The 2.2K might be too strong and 22K would be a little weak with the C55 combination. If you remove just the C55 with 22K resistor, it might work just you expected.

Regards,

TsiChung

[hamimonsarrat-c]

Hi,

I finally found a usable 10k resistor.

I did the patch very carefully and measured 10kOhms between SW3_pin1-PTA4 and J6_pin2-P3V3.

I observed the same as when I used the 2.2k and 22k: no boot-up. (with C55 stuffed)

You might want to take a look at this.

For now, I'll be fine with the C55 removal fix but I'll be waiting for your final take on this.

I am attaching one of my test board bottom layer picture in case it could be useful.

[philip_drake]

The external pull up is keeping the MCU from entering EZPORT mode after the reset is de-asserted.  If EZPORT is enabled in the FOPT register, a reset with EZPORT_CS high is needed to get out of EZPORT mode.  The Cap slows down the voltage rise of the pin so it could be interfering with the correct mode entry.

If EZPORT is disabled and NMI is enabled and if the pin is below VIH then the NMI interrupt vector is fetched.   There is no masking it aside from disabling it.  If you want to correctly handle this eventuality and disable the NMI in your code and not in the FOPT then creating an NMI interrupt service routine that changes the pin functionality to GPIO input with pull enabled is a good option.

Something like this.

// called on NMI

void Cpu_OnNMIINT(void)

{

SIM_SCGC5 |= (uint32_t)SIM_SCGC5_PORTA_MASK; /* NMI and PORTA clock gate enable */

PORTA_PCR4 &= PORT_PCR_MUX_MASK;

       /* enable input with pull up enable not NMI */

PORTA_PCR4 |= PORT_PCR_MUX(01) | PORT_PCR_PE_MASK | PORT_PCR_PS_MASK;

       return;

}

Removing the cap without adding an external resistor might be sufficient as there is an internal pull device on this pin.  But to insure that the MCU enters run mode and boots, an external resistor, without the cap is suggested.  I'm not sure why a cap was put on this pin on the FRDM board. 

[hamimonsarrat-c]

After a suggestion from 0xc0170 from the mbed community, I changed in startup_MK64F12.s,

    ;   <h> Flash nonvolatile option byte (FOPT)

    ;     <i> Allows the user to customize the operation of the MCU at boot time.

    ;     <o.0>  LPBOOT

    ;       <0=> Low-power boot

    ;       <1=> normal boot

    ;     <o.1>  EZPORT_DIS

    ;       <0=> EzPort operation is enabled

    ;       <1=> EzPort operation is disabled

    FOPT            EQU     0xFF

for

    ;   <h> Flash nonvolatile option byte (FOPT)

    ;     <i> Allows the user to customize the operation of the MCU at boot time.

    ;     <o.0>  LPBOOT

    ;       <0=> Low-power boot

    ;       <1=> normal boot

    ;     <o.1>  EZPORT_DIS

    ;       <0=> EzPort operation is disabled

    ;       <1=> EzPort operation is enabled

    FOPT            EQU     0xFD

which fixes the problem. (The board now boots fine.)

I noticed that the EzPort state appears to be inverted in the original comments.

(according to K64 sub family reference manual)

Could someone from Freescale confirm this?

[giacomopetrini]

Hello,

I'm having the same issue.

Problem is: I created a project using KSDK 1.0.0 and PEx, but in my startup_MK64F12.S I have no "FOPT   EQU     0xFF" instruction (there is nowhere in the project something related to FOPT).

Any ideas? Changing R75 or C55 is not really feasible.

Thanks

Regards Giacomo

[giacomopetrini]

Ok, found out.

It's "hidden" in the flash config section:

/* Flash Configuration */

    .section .FlashConfig, "a"

    .long 0xFFFFFFFF

    .long 0xFFFFFFFF

    .long 0xFFFFFFFF

    .long 0xFFFFFFFE

    .equ _NVIC_ICER0, 0xE000E180

    .equ _NVIC_ICPR0, 0xE000E280

    .text

    .thumb

changed to this:

/* Flash Configuration */

    .section .FlashConfig, "a"

    .long 0xFFFFFFFF

    .long 0xFFFFFFFF

    .long 0xFFFFFFFF

    .long 0xFFFFFDFE

and now it seems to work.

Thanks Bye

Giacomo

[dean_jia]

About the EZPORT_DIS bit in FOPT register, set 1 to enable EzPort mode and 0 to disable it. Please refer to the reference manual. (page 211 of K64P144M120SF5RM  http://cache.freescale.com/files/microcontrollers/doc/ref_manual/K64P144M120SF5RM.pdf?fasp=1&WT_TYPE...).

This is the capture from K64P144M120SF5RM.

[hamimonsarrat-c]

I'll try this software fix shortly.

Thanks!

[dean_jia]

Now we can confirm this issue comes from  the “PTA4 /NMI/EZP_CS” pin. So I disabled the EzPort mode by clearing the EZPORT_DIS bit of FOPT, then the issue would not exist. And if only the NMI_DIS bit is cleared, the issue would not be fixed. Thus we can deduce chip enters EzPort mode when fails to startup.

The phenomenon of this issue can be explained as follows. when system is getting out from POR(power-on-reset), C55(between the pin and ground) is still charging and it’s voltage has not got to enough level, then chip will enter EzPort mode and not startup. If we power the board off and power on again in a short time, C55’s remained charge is still holding some voltage, ant then it can startup normally.

To testify this point, I captured the waveform of RESET pin and PTA4 pin during the power-on and power-off process, as shown in the following figures. The yellow waveform is for RESET pin and the blue one is for PTA4.

                                                power-on process

                                               power-off process

By the way, the parasitic capacitance of the oscilloprobe may have affect on the measuring result.

Now we can solve this problem by one of the following solutions: 1) pasting proper resister for R75 and proper capacitor for C55; 2) removing C55 directly; 3) disabling EzPort mode by clearing the EZPORT_DIS bit.

If the NMI is enabled, the NMI handler is also needed on the safe side.

[hamimonsarrat-c]

Hi,

I just did some observations.

It appears that the mbed firmware was already implementing the PTA4 to input configuration

in NMI vector suggested earlier.

Thus, the vector was present in my earlier tests.

Everything being in its default out-of-manufacture state + FOPT register value being 0xFF,

it appears that the NMI vector is not even called

when I power ON the board from the K64F USB port and get into its locked state.

I got that result assigning led states in the NMI vector.

What possibility does it leave us in terms of software patch?