What exactly does the debugger do to execute your program?

[dave408]

I have a problem where a particular PCB with a K64F will run via the debugger in KDS, but when I power cycle it, the program does not execute.  I have already tried the approach suggested in one of my previous posts: How do you program and run from flash?

However, 1/3 of my boards (same revision PCB) does boot on startup.  I'm trying to understand why this is the case.

Since all of the boards work when debugging under KDS, I'm interested in knowing exactly what happens.  My simplified guess would be:

• flash program
• verify program
• reset processor
• send go command

I have used the J-Link Commander to flash my hex image, then I reset the processor and sent the go command.  My program does not run.  I must be missing some important steps here!  While it is necessary for me to eventually get the program to run on powerup, for the time being, it will be good enough if I can "kick start" the execution of the program via J-Link Commander commands.

Can anyone provide me with some more information about what's happening under the hood when the KDS debugger runs?  Thank you!

p.s. any suggestions about what I should look at with the scope to determine why the program isn't running on powerup would be much appreciated as well!

[Jorge_Gonzalez]

Hello Dave:

I could not say exactly how the GDB debugger works apart from what you mentioned (reset processor could instead be loading the Program Counter and sending Go command would be to release the Core from debug Halt mode). Moreover it depends on the programming tool, each manufacturer creates their own programming algorithms (Segger, P&E Micro).

Based on your issue what I can recommend you is to check that the NMI/EzPort pin on your custom boards is not pulled low by an external signal. See the next discussion about a similar problem:

FRDM-K64F booting issue when powered from USB port

The next document is related, although it is for the opposite situation, the application not working in Debug mode:

Interrupts appear to be disabled when debugging.pdf

Regards!
Jorge Gonzalez

[dave408]

Hi Jorge, thanks for your reply.  I've been trying to mess with the NMI settings, but it seems like everything available online at the moment doesn't accurately represent what I'm seeing in KDS 3.0.  I don't see any NMI or EzPort settings anywhere, even when I enable the advanced view and switch off tabbed views.

I therefore added NMI_Handler manually as described in your referenced post to try to force the pin to be an input and not be NMI:

void NMI_Handler(unsigned long *hardfault_args)
{
    // https://community.freescale.com/thread/332195
    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;
}

That did not help.  At this point, I think I'll have to desolder the cap between PTA4 and GND.

Do you have any other suggestions about what I can try in the latest KDS (3.0)?  Is there any updated information on configuring EzPort and NMI with this IDE?

[Jorge_Gonzalez]

Hello Dave:

Actually the main issue is the EzPort mode, not the NMI handler. If the pin detects a low level at Power ON, then it will enter EzPort mode, so it won't even get to trigger the NMI interrupt. It would be better if you desolder the capacitor.

EzPort can also disabled. If you are using KSDK, then the Flash configuration registers are not handled by Processor Expert. In the first discussion I linked you can see there is a file called startup_MK64F12.S which contains the Flash Configuration:

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

Change it to this to disable EzPort and NMI (see the F9):

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

Regards!

Jorge Gonzalez

[dave408]

Hi Jorge, unfortunately, when I did that, two things happened.  First, when I boot, the code still doesn't execute.  Secondly, when I try to run through the debugger, my flash codes indicate a MemManage fault.