<?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 Re: QE128 Flash problem in 8-bit Microcontrollers</title>
    <link>https://community.nxp.com/t5/8-bit-Microcontrollers/QE128-Flash-problem/m-p/245969#M19682</link>
    <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Hi,&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;there is errata for flashing QE128 - take a look into&lt;/P&gt;&lt;P&gt;&lt;STRONG&gt;&lt;STRONG style="font-family: Arial;"&gt;&amp;nbsp; &lt;/STRONG&gt;&lt;/STRONG&gt;&lt;/P&gt;&lt;P&gt;SE133-FLASH: Unexpected Flash Block Protection Errors&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;this is also in conformity with your statement of dual erase.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;&lt;A href="http://cache.freescale.com/files/microcontrollers/doc/errata/MSE9S08QE128_0M11J.pdf?fpsp=1&amp;amp;WT_TYPE=Errata&amp;amp;WT_VENDOR=FREESCALE&amp;amp;WT_FILE_FORMAT=pdf&amp;amp;WT_ASSET=Documentation"&gt;http://cache.freescale.com/files/microcontrollers/doc/errata/MSE9S08QE128_0M11J.pdf?fpsp=1&amp;amp;WT_TYPE=Errata&amp;amp;WT_VENDOR=FREESCALE&amp;amp;WT_FILE_FORMAT=pdf&amp;amp;WT_ASSET=Documentation&lt;/A&gt;&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;hope this helps&lt;/P&gt;&lt;P&gt;Pavel&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
    <pubDate>Tue, 24 Sep 2013 12:05:52 GMT</pubDate>
    <dc:creator>pavel_sadek</dc:creator>
    <dc:date>2013-09-24T12:05:52Z</dc:date>
    <item>
      <title>QE128 Flash problem</title>
      <link>https://community.nxp.com/t5/8-bit-Microcontrollers/QE128-Flash-problem/m-p/245966#M19679</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Hi all,&lt;/P&gt;&lt;P style="min-height: 8pt; padding: 0px;"&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;Some QE128-based device came back for maintenance after having spent about 5 years in the field running 24/7, and I noticed it would no longer save its configuration into its internal Flash.&amp;nbsp; Flash rewrites are not very common with this device since parameters change very rarely, if ever.&amp;nbsp; (The MCU is in a high-power RF area.)&lt;/P&gt;&lt;P style="min-height: 8pt; padding: 0px;"&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;I thought there might be some Flash corruption that affected code execution, so I loaded new firmware but the problem remained.&amp;nbsp; After some BDM debugging, I noticed the following:&lt;/P&gt;&lt;P style="min-height: 8pt; padding: 0px;"&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;The flash could not be erased &amp;amp; re-programmed unless I repeat the erase process twice (regardless if I program in between), with no significant delay in between the trials.&amp;nbsp; So, erase-erase-program or erase-program-erase-program both work.&amp;nbsp; If there is any delay (like a second or more), there is failure.&amp;nbsp; So, I ended up patching the firmware to call the configuration save routine twice, and this bypassed the problem for now.&lt;/P&gt;&lt;P style="min-height: 8pt; padding: 0px;"&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;But, I'd like to know why this happens.&amp;nbsp; I can understand Flash may be starting to fail and it's becoming harder to erase/program (e.g., needing more time for the erase), but the Flash erasing process returns without errors, even when it fails to erase.&amp;nbsp; So, how am I to know the process failed (without actually verifying each and every byte for being $FF)?&amp;nbsp; If there were an error, at least it could keep trying (say, to erase) again and again for a predefined maximum number of times, before declaring the Flash unusable.&lt;/P&gt;&lt;P style="min-height: 8pt; padding: 0px;"&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;By the way, Flash clock (FDIV) is set around the high end, 200KHz.&amp;nbsp; Would a value closer to low end (150KHz) have better results over long time?&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Mon, 23 Sep 2013 15:39:31 GMT</pubDate>
      <guid>https://community.nxp.com/t5/8-bit-Microcontrollers/QE128-Flash-problem/m-p/245966#M19679</guid>
      <dc:creator>tonyp</dc:creator>
      <dc:date>2013-09-23T15:39:31Z</dc:date>
    </item>
    <item>
      <title>Re: QE128 Flash problem</title>
      <link>https://community.nxp.com/t5/8-bit-Microcontrollers/QE128-Flash-problem/m-p/245967#M19680</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Tony, did you try to confirm that PRDIV8 and FDIV fields in FCDIV are set up correctly? Unless you write 1 to FDIVLD bit first, this piece of code&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;FCDIV_FDIV=xx;&lt;/P&gt;&lt;P&gt;FCDIV_PRDIV8 = y;&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;makes first (FDIV) assignment granted by MCU but second (PRDIV8) assignment ignored.&amp;nbsp; FCDIV is write once register, unless you keep writing 1 to FDIVLD.&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Tue, 24 Sep 2013 08:29:39 GMT</pubDate>
      <guid>https://community.nxp.com/t5/8-bit-Microcontrollers/QE128-Flash-problem/m-p/245967#M19680</guid>
      <dc:creator>kef2</dc:creator>
      <dc:date>2013-09-24T08:29:39Z</dc:date>
    </item>
    <item>
      <title>Re: QE128 Flash problem</title>
      <link>https://community.nxp.com/t5/8-bit-Microcontrollers/QE128-Flash-problem/m-p/245968#M19681</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Thanks for your suggestion.&amp;nbsp; FCDIV is written with a single instruction which combines the values for the two fields, so no possibility of this happening.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;I only write FCDIV once (the first time) decided by the current state of the DIVLD bit.&amp;nbsp; Although now I realize this checking seems redundant because you can always refresh the register for those MCUs where multiple writes are allowed, while for the rest, the extra write is simply ignored.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;After re-reading the docs (after many years because my library routines were considered stable), I guess there is no error indication for the case the command is not completed successfully, only for setup errors (FPVIOL, FACCERR).&amp;nbsp; So, a successful completion of a Flash command does not mean success, only potential success.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;So, we just need to hope that the internal timing for the ERASE/PROGRAM commands (timing for which we can't do much, other than lower the clock to prolong a bit the overall duration) is sufficient even as the chip ages.&amp;nbsp; I'll try to lower the frequency to 150KHz and see if that completes the erase in a single operation (instead of the workaround for two consecutive ones).&amp;nbsp; But even if this works for now, it's still a matter of time as the chip ages a bit more until eventually the command built-in duration will be slightly shorter than needed, again requiring double (or more) repetitions to get the total time to be enough.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Which means, the way I now understand it, the only real solution for knowing if a Flash command succeeded is to add code to verify each erase and program operation and, if the expected result isn't found, repeat the process, for up to a maximum number of times.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Additional comments / suggestions are welcome.&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Tue, 24 Sep 2013 10:29:07 GMT</pubDate>
      <guid>https://community.nxp.com/t5/8-bit-Microcontrollers/QE128-Flash-problem/m-p/245968#M19681</guid>
      <dc:creator>tonyp</dc:creator>
      <dc:date>2013-09-24T10:29:07Z</dc:date>
    </item>
    <item>
      <title>Re: QE128 Flash problem</title>
      <link>https://community.nxp.com/t5/8-bit-Microcontrollers/QE128-Flash-problem/m-p/245969#M19682</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Hi,&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;there is errata for flashing QE128 - take a look into&lt;/P&gt;&lt;P&gt;&lt;STRONG&gt;&lt;STRONG style="font-family: Arial;"&gt;&amp;nbsp; &lt;/STRONG&gt;&lt;/STRONG&gt;&lt;/P&gt;&lt;P&gt;SE133-FLASH: Unexpected Flash Block Protection Errors&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;this is also in conformity with your statement of dual erase.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;&lt;A href="http://cache.freescale.com/files/microcontrollers/doc/errata/MSE9S08QE128_0M11J.pdf?fpsp=1&amp;amp;WT_TYPE=Errata&amp;amp;WT_VENDOR=FREESCALE&amp;amp;WT_FILE_FORMAT=pdf&amp;amp;WT_ASSET=Documentation"&gt;http://cache.freescale.com/files/microcontrollers/doc/errata/MSE9S08QE128_0M11J.pdf?fpsp=1&amp;amp;WT_TYPE=Errata&amp;amp;WT_VENDOR=FREESCALE&amp;amp;WT_FILE_FORMAT=pdf&amp;amp;WT_ASSET=Documentation&lt;/A&gt;&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;hope this helps&lt;/P&gt;&lt;P&gt;Pavel&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Tue, 24 Sep 2013 12:05:52 GMT</pubDate>
      <guid>https://community.nxp.com/t5/8-bit-Microcontrollers/QE128-Flash-problem/m-p/245969#M19682</guid>
      <dc:creator>pavel_sadek</dc:creator>
      <dc:date>2013-09-24T12:05:52Z</dc:date>
    </item>
  </channel>
</rss>

