Bootloader failure during write over I2C

johannagunter · ‎09-14-2016

While attempting to write to FLASH during an update via I2C (in BSL mode) the process was interrupted. When this happens, the Microcontroller will no longer respond to any bootloader commands via I2C. The only recovery is through the emulator. Is there a method by which we can get the micro to respond and restart the process? We're working with the MKL03Z32CAF4R device.

alejandronavarr · ‎03-15-2017

Hi all,

I am facing exactly the same problem: if the firmware update is interrupted due to any cause (power failure, hardware issues on the I2C bus, etc.), the bootloader cannot respond anymore.

Although not reproducible, we have been able to successfully ping the bootloader sometimes, but the update process cannot be restarted. Then, the bootloader apparently accepts the "erase flash" message, but no ACK is sent back to the master.

So I would like to know in which state the bootloader remains after the failure of the write command, and if it is possible to return to a consistent state from which we can retry the update process. I would not expect the KL03 to be recoverable only by using an emulator probe, since end products could be shipped to customers who do not have an emulator or, even worse, the board with the microcontroller could be assembled into a housing that does not provide access to an emulator probe.

Thank you very much in advance for your answer.

Best regards,

Alejandro

jeremyzhou · ‎09-21-2016

Hi Johanna Gunter,

Before answer the question, I'd like to know whether the bootstrap loader was designed by yourselves or not.
Have a great day,
Ping

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

johannagunter · ‎09-22-2016

No, we are using the kinetis blhost application. We sometimes get interrupted on a write to memory and once that happens, we can no longer ping. When we run the emulator, it says the device is secure and we can reprogram from there, but we have not been able to communicate with the bsl to do the same thing serially.

jeremyzhou · ‎09-25-2016

Hi Hi Johanna Gunter,

The KBOOT has provided the BusPal as a companion to Blhost and the KL03 is allow to be reprogrammed through the I2C interface by using the BusPal to interface Blhost and target device as the Fig 1 shows.

Fig 1

So I was confused with the interrupt happening, obviously the target device can't arise any interrupts while the target enter the Bootloader mode.

Can you explain it please?
Have a great day,
Ping

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

johannagunter · ‎10-03-2016

When I said interrupted, I meant we were in process of writing to memory (after flash erase all) and the transfer did not complete. So, the transfer did not write a full image to flash before it was stopped, either by the user, or maybe even a power failure. Once we reset power, we can no longer communicate with the bsl.

jeremyzhou · ‎10-03-2016

Hi Johanna Gunter,

Sorry, the KBOOT hasn't supported the kind of feature up to now.

The firmware updating procedure mustn't be interfered, it's the premise.

Have a great day,
Ping

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

johannagunter · ‎10-04-2016

If an invalid FLASH image is written, I thought the bsl would still be operational - just not jump to FLASH (on a reset or power up). The emulator is able to overcome this problem and 'unsecure' the device to overwrite FLASH. I thought there might be a way to do this over the bsl serial interface. There are commands to 'unsecure', etc, but without the serial interface acknowledgements, this cannot happen. Thank you for your input, but I'm concerned that there is no fault recovery mechanism in this case.