Clearing PTA1 freezes program on MKL17Z256

[paulinikula]

I'm experiencing a strange problem with a MKL17Z256VFM4 controller that I'm working on. I set PTA1 as GPIO output pin, and I can drive the pin high without problem, but as soon as I program it to drive low, it apparently freezes the MCU. PTA2 can toggle without problem, also other pins that I have tested.

CLOCK_EnableClock(kCLOCK_PortA);
PORT_SetPinMux(PORTA, 1u, kPORT_MuxAsGpio);
PORT_SetPinMux(PORTA, 2u, kPORT_MuxAsGpio);

GPIO_PinInit(GPIOA, 1u, &LED_configOutput);
GPIO_PinInit(GPIOA, 2u, &LED_configOutput);

//GPIO_ClearPinsOutput(GPIOA, 1<<1u);  //if I uncomment this, program will freeze and PTA2 will not toggle in loop

//del(); //a test delay. With this delay, program does not advance to the PTA2 toggle loop before freezing. Without delay it toggles PTA2 at least once before freezing.

for(;;) { 
GPIO_PortToggle(GPIOA, 0x00000004); //toggle PTA2 to see if program is running
del(); //delay
}

If I program PTA1 as TPM2 timer output channel, I can generate PWM perfectly fine with it! But it will still freeze the main program! I suspect that the timer keeps running on its own although the MCU core has freezed for some reason. I have tried swapping the chip and that did not make a difference. I have checked that I don't have a short on PCB on PTA1.

Edit:

I think this might be related to the internal ROM bootloader using the PTA1 pin as UART RX pin, and also possibly a USBDM bug.. Now I have found out that PTA1 works if I program the FOPT byte to boot directly from flash. If I leave the factory boot from ROM setting, the problem will appear. Now the funny thing is that USBDM flash programmer does not modify the FOPT byte until I do a small code change, recompile and reload the hex file, although the correct FOPT byte has been in my code all the time. If I select "Security: Unsecure" on USBDM flash programmer, it will program the factory FOPT byte and problem appears. Then if I select "Security: Image" so it should program FOPT byte defined by my code, it will not do it and MCU will still boot from ROM, until I recompile my code and re-flash!

[kerryzhou]

Hi Pauli,

    You are correct , this problem is related to the ROM bootloader.

    Please check my document about this phenomena and the solutions:

Problem Analysis and solutions for booting from ROM BOOTLOADER in KL series 

Wish it helps you!

Have a great day,
Kerry

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

[paulinikula]

Hi Kerry

Thank you, that was helpful. Interesting that the errata only states that the pin mux is affected.