KL17x Fresh Chip, First Boot - Questions

[rodrigon_hernan]

Hello there,

I'm in the task of laying down a fresh KL17 chip in a minimal PCB to start trying it out and start development(hardware/software). I'm used to the 8bit micros world and actually having a big time with chip's datasheet and user manual, trying to understand what it takes to be able to start. I have some questions/confirmations I would like to clarify to avoid trouble, or damaging/bricking the chip. Also to confirm if my expectations are correct:

1- User manual states that default reset clock for core/system clock is 8 MHz from IRC8M. So, initially, I don't need a external crystal to make it work and communicate using the bootloader, that's right?

2- Datasheet states that chip came with a pre loaded bootloader from the factory. The part identification numbers/letters doesn't let me know what bootloader version is. I will be able to make a first contact using the actual tools from download section in case it's some old version?

3- Considering is a new chip I guess all flash memory is uninitialized with 0xFF, that's all BCA values will be "1". The first configuration field bootloader is the magic number (that must be 'kcfg'). By the other hand is stated that "For uninitialized flash, the Kinetis Bootloader uses a predefined default configuration", so I can expect it will just set the magic number right in the first reset sequence? Later on if I perform a entire flash erase this default configuration sequence will be triggered again?

4- I don't know what are these default configurations but I expect values on BCA being 1 for what I read on user manual. That's, all peripherals will be activated/clocked by default, that's right?

5- There's anything like bricking the device? Or it's always some possibility to reset the device? From the 8bit micros I'm used to use a high voltage programmer to reset the chip if any #### happens.

6- For what I understand from bootloader user docs is that I will be able to make contact using the tools and the PC as host, directly from UART. My intention is interfacing UART directly to PC COM port using a TTL<->RS232 level converter. Is correct understanding that it will work this way?

Sorry about the amount of questions or if there are stupid ones, any clue that could me lead on the right direction is greatly appreciated!

Thanks

[ramboyang · Accepted solution]

Hi Rodrigo,

Let me try to answer your conern's one by one.

1. Yes, no additional OSC is required before communicating to Bootloader

2. Actually, there is a BootROM in the K17 chip. The BootROM version is fixed, there is no way to update it. Please use the host tool within Kinetis Bootloader V2.0 release package to communicate to the device (it is availabe at www.nxp.com/kboot), the host tool will display the bootROM verision.

3,4.The entire flash array are 0xFFs except the value at 0x40C, it is 0xFE (device is under unsecure state). Be aware that the bootloader configuration area(BCA) is specifed in user application starting at address 0x3C0 with valid tag ('kcfg'), withtout valid tag, BootROM treats it as invalid BCA and uses predefined BCA in ROM instead. The predefined BCA is as follows:

  (1): All feilds in BCA are all 0xFFs.

  (2): That means:

• All of supported SPI, I2C and UART are enabled,
• Perierpheral detection timeout is 5000ms.
• High clock enable flag is false, clock divider is disabled.
• Bootloader works at 8MHz core clock if FOPT is 0xFFs, otherwise, the core clock is divided by the devider specified by the combination of FOPT[0] and FOPT[4].

5. Yes, it is possbile to brick the device if FSEC is programmed with wrong value, please refer to FTFA chapter for more details, it is beyond BootROM scope.

6. Yes, your understanding is pretty right. Please use the host tool in Kinetis Bootloader 2.0 package for this purpose, either blhost or KinetisFlashTool is OK.

Hope above answer could be helpful to you.

Have a great day!

[rodrigon_hernan]

Hi Fan Yang,

Many thanks it's surely helpful.

About bricking/locking chip access:

1- If I had dumped "backdoor access key" previously and set the chip secure by adjusting the 0x40C byte to 0xFF I'm still       able to unlock security using the FlashTool or alternatively, performing "mass erase" using a SWD programmer?

2- If I set FTFA_FSEC field MEEN to "mass erase disabled" and SEC field to "status secure" then the chip is locked forever,       no way to unlock it externally?

3- On the same case (MEEN disabled and SEC security enabled), I'm still able to unlock the chip if I had previously set       some valid code under user application area that sets these bits back to default, as "CPU accesses to the       flash are       not       affected by the status of FTFA_FSEC", this is right?

Well inform me if is best I replicate this question in other forum space as it's not entirely specific to KBOOT.

Cheers,

Rodrigo

[ramboyang]

Hi Rodrigo,

1. As long as the MEEN is not disabled, the device can be unlocked using either SWD or BootROM even Flash is under secured state.

2. If the MEEN is disabled while the SEC is enabled, the flash still can be programmed via BootROM if the Backdoor key is enabled, in this case, please use flash-security-disable command to bypass the security protection

3. If MEEN is disabled, SEC is enabled, Backdoor key is disabled, the only way to update the flash is the application pre-programmed in the internal Flash.

Best Regards,

Fan

[rodrigon_hernan]

Thanks Fan,

Now, for all I read from the user manual and this discussion this is a really unexpected situation:

The first thing I did after powering my fresh chip for the first time was connecting to bootloader using the FlashTool. It connected as expected but the "Security State" field was marked as "SECURE". I attached a picture with information that's show in the FlashTool connection screen.

Tried blhost and queried for available commands, it returned "Available Commands = flash-erase-all, flash-erase-region, read-memory, write-memory, flash-security-disable, get-property, execute, reset, set-property, flash-erase-all-unsecure"

I guess the only command I cant use at this point is "flash-erase-all-unsecure". It returned:

"Ping responded in 1 attempt(s)
Inject command 'flash-erase-all-unsecure'
Successful generic response to command 'flash-erase-all-unsecure'
Response status = 0 (0x0) Success."

Despite of that, chip still marked as SECURE connecting to it right after the erase command. Tried "read-memory" also but with same response about enabled security.

This on arrive SECURE state was a surprise for me. Clearly a bug/defect either on the user manual, the bootloader (in case it turned security ON by itself), or at the factory while formatting/initializing this chip, anything else:

I think is weird that it reports Flash Reserved Regions 0x00 - 0x00. Same result with blhost command "get-property 12". Maybe because chip is secure, it doesn't even read this information? Or maybe I managed to damage the flash? :smileysad:

Any clue about what I should do to unsecure the chip from now?

Regards

[ramboyang]

Hi, Rodrigo,

1. I am not clear about the default factory setting of the chip, it is beyond BootROM scope. maybe the entire flash are all 0xFFs, in this case, the device is under secured state(FSEC=0xFF).

2. The Flash security state is determined by FSEC register, which is loaded from 0x40C during HW power up sequence, and cannot be changed by any SW codes, so even with flash-erase-all-unsecure command, a  subsequence reset command is required to refresh the FSEC register.

3. The reserved region 0-0 means there is no reserved region on the internal flash, in other words, the entire flash is availabe to be programmed.

Hope about info helps.

Have a great day!

[rodrigon_hernan]

Update:

It seems that I really damaged the chip, or other thing happened. I soldered a second chip and I got "UNSECURE" flag upon first contact.

I had to rework the first one, had issues while soldering and it was quite stressing. Chances are I just killed some of the flash or something.

Now I'm tempted to secure it on purpose and watch how mass erase behaves, but no.... this was the second and it's the last chip I have :smileyhappy:

Salute,

Rodrigo

[ramboyang]

Hi Rodrigo,

Based on the phenomenon described above, it looks like the  opearating temperature exceeds the soldering temperature mentioned in datasheet, so the FTFA may be demaged forever, though the chip still can work sometimes,it can no longer work stably.

This guess can explain why the second K17 works normally on your board, and why we never saw this issue on the NXP Freedom board.

Hope it helps.

Best Regards,

Fan