topic Re: Difficulties using KL27 BOOT ROM in Kinetis Microcontrollers

Difficulties using KL27 BOOT ROM

mjbcswitzerland — Wed, 07 Dec 2016 15:48:39 GMT

Hi All

I am preparing the production of a new line of KL27 based USB devices where I plan to use the internal BOOT ROM loader for initial factory programming. In order to do some verification I have taken the FRDM-KL27Z to run through the process.

Initially I started with a blank chip and could program the application (in fact a secondary boot loader that will be used in case of firmware upgrades directly from the product's PC application). This is therefore fine for usual production circumstances.

However, in case of emergencies it is also possible to use the BOOTCFG0 input to get back to the internal BOOT ROM, but this wasn't working as expected. I found that the application starts normally if the BOOTCFG0 is not asserted but the board just hangs when it is asserted - there is no USB enumeration and it doesn't react to the reset anymore even when the BOOTCFG0 is no longer applied - basically it needs a power cycle to recover. The mask of the chip on the board is 1N87M which doesn't have any references to such behavior (I know that some masks have a problem if the SPI lines float since it may falsely enable SPI loading mode).

Note that I don't configure the BCA area (it is all 0x00 and thus invalid, causing all interfaces to be active - same as a fresh chip).

Thinking that this were a BOOTCFG0 issue I also tested forcing the ROM loader in the flash config setting. In this case it starts the application after about 5s but still no USB enumeration.

Rather than panicking I did some careful comparisons and actually found that both of the configurations (forced ROM or BOOTCFG0 commanded) actually work as long as I leave the FRDM-KL27Z powered off for about 30s or so before connecting and powering over USB; then it appears as USB device for 5s and there is just enough time to attach KBOOT host and reprogram it.

If the reset button is used it never works; if the power is removed for only a few seconds it never works but if one is patient enough to power down for long enough it can indeed be used.

This means that it is probably safe to continue as planned but the question remains as to whether this is caused by a BOOT ROM errata that is not published for this device on the FRDM-KL27Z or whether there is some other explanation?

Regards

Mark

Update 1: Original tests on Win 8.1 PC with Kinetis Updater program.
Repeats on Win 10 PC using "KinetisFlashTool.exe" showed no such difficulties.

Update 2: If the BOOT ROM mode is entered by forcing it with BOOTCFG0 it is possible to command a reset from "KinetisFlashTool.exe" and the application starts after about 5s delay. If "KinetisFlashTool.exe" is not connected the HW reset button doesn't cause the application to start and a power cycle is required. Can this be explained?

Re: Difficulties using KL27 BOOT ROM

bobpaddock — Wed, 07 Dec 2016 21:43:19 GMT

The five second delay is normal, and annoying. After bootloading I always disconnect the cable (which in our hardware is connected to the boot pin) then cycle power.
It is imperative that NMI be disabled for any of this to work correctly.

This is my flash config area and the function below, is the key to making it work correctly:

/* Flash configuration field: */
const uint8_t _kfcf[] __attribute__( ( section( ".kinetis_flash_config_field" ) ) ) =
{ [Not my real key]
0x33U, /**< Backdoor Comparison Key 3., offset: 0x0 NV_BACKKEY3 */
0x22U, /**< Backdoor Comparison Key 2., offset: 0x1 NV_BACKKEY2 */
0x41U, /**< Backdoor Comparison Key 1., offset: 0x2 NV_BACKKEY1 */
0x40U, /**< Backdoor Comparison Key 0., offset: 0x3 NV_BACKKEY0 */
0x27U, /**< Backdoor Comparison Key 7., offset: 0x4 NV_BACKKEY7 */
0x66U, /**< Backdoor Comparison Key 6., offset: 0x5 NV_BACKKEY6 */
0x95U, /**< Backdoor Comparison Key 5., offset: 0x6 NV_BACKKEY5 */
0x84U, /**< Backdoor Comparison Key 4., offset: 0x7 NV_BACKKEY4 */

0xFFU, /**< Non-volatile P-Flash Protection 1 - Low Register, offset: 0x8 NV_FPROT3 */
0xFFU, /**< Non-volatile P-Flash Protection 1 - High Register, offset: 0x9 NV_FPROT2 */
0xFFU, /**< Non-volatile P-Flash Protection 0 - Low Register, offset: 0xA NV_FPROT1 */
0xFFU, /**< Non-volatile P-Flash Protection 0 - High Register, offset: 0xB NV_FPROT0 */

/*
* FTFA_FSEC 0x040C:
*
* Note: The security features apply only to external
* accesses: debug. CPU accesses to the flash
* are not affected by the status of FTFA_FSEC.
*
* In the unsecured state, all flash commands are available on the
* programming interfaces either from the debug port (SWD) or user
* code execution. When the flash is secured (FTFA_FSEC[SEC] = 00,
* 01, or 11), the programmer interfaces are only allowed to
* launch mass erase operations. Additionally, in this mode, the
* debug port has no access to memory locations.
*
* KEYEN MEEN FSLACC SEC
* 7 6 5 4 3 2 1 0
*
* KEYEN = 0x01 Backdoor Disabled.
* KEYEN = 0x10 Backdoor Enabled.
*
* MEEN = 0x10 Mass Erase Disabled. All others Mass Erase Enabled.
*
* FSLACC Factory Security Level Access Code
*
* FSLACC = 0x01 or 0x11 Factory access granted. Others denied.
*
* SEC Flash Secutiry
*
* SEC = 0x10 Unsecure (0x7EU) which is the factory shipping state. 0xFEU is also unsecured which is what flash-erase-all-unsecure does.
*/

//0x7EU, /**< Non-volatile Flash Security Register, offset: 0xC NV_FSEC. Backdoor Disabled, Unsecured */
//0xBEU, /**< Non-volatile Flash Security Register, offset: 0xC NV_FSEC. Backdoor enabled, Unsecured */
0xBFU, /**< Non-volatile Flash Security Register, offset: 0xC NV_FSEC. Backdoor enabled, Secured */

/*
* FTFA_FOPT 0x04D:
* 7:BOOTSRC_SEL1 0x80U
* 6:BOOTSRC_SEL0 0x40U
* 00 = Flash, 01 = Reserved, 10/11 = ROM
*
* 5:NV_FOPT_FAST_INIT_MASK 0x20U
* 1 = Fast
*
* 4:NV_FOPT_LPBOOT1_MASK 0x10U
* See bit zero
*
* 3:NV_FOPT_RESET_PIN_CFG_MASK 0x08U
* 0 = Disabled Reset.
*
* 2:V_FOPT_NMI_DIS_MASK 0x04U
* 0 = Disable NMI
*
* 1:BOOTPIN_OPT 0x02U
* 0 = Force boot from ROM if BOOTCFG0 asserted.
*
* 0:NV_FOPT_LPBOOT0_MASK 0x01u
* 00 /8 VLPR on exit reset
* 01 /4 VLPR on exit reset
* 10 /2 RUN on exit
* 11 /1 RUN on exit
*
*/
0x38U, /**< Non-volatile Flash Option Register, offset: 0xD NV_FOPT Disable NMI pin. Boot from Flash not ROM */

0xFFU, /* Not used. Required to hold position to align vector table correctly */
0xFFU
};

You quested errata:

static void vectors_bootloader_mr_setup( void );
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. [Doesn't actually make sense, is what the data sheet says.]
*
* A reset is forced to clear out anything that the ROM
* bootloader did, so we are sure we have the data sheet reset
* values. [Which are Vcc Rise not all reset sources.]

* 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 */
}
}

void _reset_init(void)
{
irq_disable(); /* Did bootloader leave IRQs on perhaps? */

bootloader_mr_setup();

SCB_VTOR = (uint32_t) interrupt_vector_table;
sync_barrier_data();

...

Re: Difficulties using KL27 BOOT ROM

bobpaddock — Wed, 07 Dec 2016 21:49:32 GMT

"KinetisFlashTool.exe"

Found it to be a crap shoot if that works on any given PC.

On the PCs where it does not work *nothing* happens.

Zip, nothing, like you did not even click on the icon.

I always use bhost.exe in a batch file.

It is not uncommon to see the board cycling at power up, have never figured out why.
A reset stops the cycling.

Helpful to have this running to tell when things are really connecting:

View any installed/connected USB device on your system
It is most useful when configured to not show disconnected devices.