Yes the KL27 has the ROM bootloader built in.
To work around a bug it has call this function right out of reset:
static void vectors_bootloader_mr_setup( void ) __attribute__( ( used, __aligned__( 4U ), section( ".after_vectors" ) ) );
static void vectors_bootloader_mr_setup( void )
{
/*
* RCM_MR Indicates the boot source, the boot source remains set
* until the next System Reset or software can write logic one to
* clear the corresponding mode bit. While either bit is set the
* NMI input is disabled and the vector table is relocated to the
* ROM base address at 0x1C00_0000. These bits should be cleared by
* writing logic one before executing any code from either Flash or
* SRAM.
*
* A reset is forced to clear out anything that the ROM
* bootloader did, so we are sure we have the data sheet reset
* values.
* This method works around the buggy KL43/27/17 bootloaders as
* described in: "Problem Analysis and solutions for booting from
* ROM BOOTLOADER in KL series".
*/
if( 0U != ( RCM_MR & RCM_MR_BOOTROM_MASK ) )
{
RCM_MR = RCM_MR_BOOTROM_MASK; /* Clear the bits that indicated a bootlaoder boot via ROM */
RCM_FM = 0U; /* Boot from Flash not ROM on next reset */
SCB_AIRCR = ( SCB_AIRCR_VECTKEY( 0x05FAU ) | SCB_AIRCR_SYSRESETREQ_MASK ); /* Force a Software Reset */
}
}
Also in case you are not aware the KL27 has problems with I2C repeated-start. It is discussed in the forum here. The IDE inserts undocumented NOPs to work around the race condition.
See Appendix-A in Mark's document:
https://www.utasker.com/docs/uTasker/uTasker_I2C.pdf
