<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic MCU boot failure after flash update in Kinetis Microcontrollers</title>
    <link>https://community.nxp.com/t5/Kinetis-Microcontrollers/MCU-boot-failure-after-flash-update/m-p/473485#M28735</link>
    <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;I wrote my own boot loader to program an allocated section in the flash memory. Erase and program seem to work, my code also performs a post updatezero checksum test for the particular mem section and it passes. I can also tell the program update works by viewing the memory window after update. However the micro failed to boot&amp;nbsp; and run after power cycle.&lt;/P&gt;&lt;P&gt;So I re-ran the the update sequence. This time I noticed both Flash Option Register (FOPT) @ 0x40c and &lt;/P&gt;&lt;P&gt;Flash Security Register (FSEC) @ 0x40d now containing different settings, after the erase call (by invoking the stand API FlashEraseSector()) . Instead of 0x3ffe. they now read as 0xffff. According to the KL17 reference manual, 0xfe read of FSEC indicates MCU flash secure status. Would it prevent the micro from running?&amp;nbsp; &lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
    <pubDate>Fri, 13 May 2016 20:41:11 GMT</pubDate>
    <dc:creator>Ming</dc:creator>
    <dc:date>2016-05-13T20:41:11Z</dc:date>
    <item>
      <title>MCU boot failure after flash update</title>
      <link>https://community.nxp.com/t5/Kinetis-Microcontrollers/MCU-boot-failure-after-flash-update/m-p/473485#M28735</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;I wrote my own boot loader to program an allocated section in the flash memory. Erase and program seem to work, my code also performs a post updatezero checksum test for the particular mem section and it passes. I can also tell the program update works by viewing the memory window after update. However the micro failed to boot&amp;nbsp; and run after power cycle.&lt;/P&gt;&lt;P&gt;So I re-ran the the update sequence. This time I noticed both Flash Option Register (FOPT) @ 0x40c and &lt;/P&gt;&lt;P&gt;Flash Security Register (FSEC) @ 0x40d now containing different settings, after the erase call (by invoking the stand API FlashEraseSector()) . Instead of 0x3ffe. they now read as 0xffff. According to the KL17 reference manual, 0xfe read of FSEC indicates MCU flash secure status. Would it prevent the micro from running?&amp;nbsp; &lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Fri, 13 May 2016 20:41:11 GMT</pubDate>
      <guid>https://community.nxp.com/t5/Kinetis-Microcontrollers/MCU-boot-failure-after-flash-update/m-p/473485#M28735</guid>
      <dc:creator>Ming</dc:creator>
      <dc:date>2016-05-13T20:41:11Z</dc:date>
    </item>
    <item>
      <title>Re: MCU boot failure after flash update</title>
      <link>https://community.nxp.com/t5/Kinetis-Microcontrollers/MCU-boot-failure-after-flash-update/m-p/473486#M28736</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Hi,&lt;/P&gt;&lt;P&gt;After had a brief look through the statement above, I found that the FOPT and FSEC registers become the different from the compete the first update&amp;nbsp; after the second update sequence.&lt;/P&gt;&lt;P&gt;It seems very weird.&lt;/P&gt;&lt;P&gt;So I'd highly recommend that you can choose the integrated ROM bootloader in your implementation,&amp;nbsp; instead of your own bootloader.&lt;/P&gt;&lt;P&gt;Wish it helps.&lt;BR /&gt;Have a great day,&lt;BR /&gt;Ping&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;-----------------------------------------------------------------------------------------------------------------------&lt;BR /&gt;Note: If this post answers your question, please click the Correct Answer button. Thank you!&lt;BR /&gt;-----------------------------------------------------------------------------------------------------------------------&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Mon, 16 May 2016 07:58:38 GMT</pubDate>
      <guid>https://community.nxp.com/t5/Kinetis-Microcontrollers/MCU-boot-failure-after-flash-update/m-p/473486#M28736</guid>
      <dc:creator>jeremyzhou</dc:creator>
      <dc:date>2016-05-16T07:58:38Z</dc:date>
    </item>
    <item>
      <title>Re: MCU boot failure after flash update</title>
      <link>https://community.nxp.com/t5/Kinetis-Microcontrollers/MCU-boot-failure-after-flash-update/m-p/473487#M28737</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;How to "program the appropriate bits in the NVM option byte"? If I can do that, I will able to ensure FOPT and FSEC registers reload the original settings properly after reset. &lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Mon, 16 May 2016 14:03:30 GMT</pubDate>
      <guid>https://community.nxp.com/t5/Kinetis-Microcontrollers/MCU-boot-failure-after-flash-update/m-p/473487#M28737</guid>
      <dc:creator>Ming</dc:creator>
      <dc:date>2016-05-16T14:03:30Z</dc:date>
    </item>
    <item>
      <title>Re: MCU boot failure after flash update</title>
      <link>https://community.nxp.com/t5/Kinetis-Microcontrollers/MCU-boot-failure-after-flash-update/m-p/473488#M28738</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Hi Ming Jiang,&lt;/P&gt;&lt;P&gt;In my opinion, you should follow the kind of produce to configure the 0x40D and 0x40C field.&lt;/P&gt;&lt;P&gt;1. First of all, you'd better to load the whole bootloader code run in the RAM instead of flash.&lt;/P&gt;&lt;P&gt;2. Next, assure the 0x40D and 0x40C field are 0xFF, in another word, the field need to be erased previously before reprogram.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&amp;nbsp;&amp;nbsp; So you can use some kind of erase commands to achieve it.&lt;/P&gt;&lt;P&gt;3. Finally, reprogram the field and other erased area by using the program longword command.&lt;/P&gt;&lt;P&gt;Hope it helps.&lt;BR /&gt;Have a great day,&lt;BR /&gt;Ping&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;-----------------------------------------------------------------------------------------------------------------------&lt;BR /&gt;Note: If this post answers your question, please click the Correct Answer button. Thank you!&lt;BR /&gt;-----------------------------------------------------------------------------------------------------------------------&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Tue, 17 May 2016 08:26:32 GMT</pubDate>
      <guid>https://community.nxp.com/t5/Kinetis-Microcontrollers/MCU-boot-failure-after-flash-update/m-p/473488#M28738</guid>
      <dc:creator>jeremyzhou</dc:creator>
      <dc:date>2016-05-17T08:26:32Z</dc:date>
    </item>
    <item>
      <title>Re: MCU boot failure after flash update</title>
      <link>https://community.nxp.com/t5/Kinetis-Microcontrollers/MCU-boot-failure-after-flash-update/m-p/473489#M28739</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;FYI I took your suggestion and reprogrammed the two bytes after sector erase. It works.&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Mon, 23 May 2016 12:08:11 GMT</pubDate>
      <guid>https://community.nxp.com/t5/Kinetis-Microcontrollers/MCU-boot-failure-after-flash-update/m-p/473489#M28739</guid>
      <dc:creator>Ming</dc:creator>
      <dc:date>2016-05-23T12:08:11Z</dc:date>
    </item>
  </channel>
</rss>

