Programming Flash Note - MC9S08QG8

[JimDon]

"Steps between command launch and command completion can not be executed out of FLASH. Since
a high voltage is applied to FLASH during these steps, FLASH cannot be read properly. Other steps
can be executed out of either FLASH or RAM."


This is a training document that says it applies to HCS08,  and uses QG8 as and example.
As far as I  know this is the only statement with regards to this aspect of writing flash.
So far, other that a single know instance of a an older demo board, this concept has not failed to be correct.

Added p/n to subject.

Message Edited by NLFSJ on 2008-03-06 11:46 AM

[allawtterb]

It the linked training document working for anyone else or is it gone?

[JimDon]

Well, somehow the link did seem to break.

Here is is fixed Link.

http://www.freescale.com/files/training_pdf/27790_HCS08_FLASH_WBT.pdf


I also wish that the editor of my post would have read the document in question, as the it clearly states:

"The intent of this course is to explain how to configure and program/erase the 9S08
FLASH memory"

Before editing the title.

Also, the title is 27790_HCS08_FLASH_WBT.pdf, not QG8. They do use the QG8 as an example, but if you read the document is says that it applies to 9s08.


The point I was trying to make is that according to this document, only starting the command and waiting for it to complete must be executed from RAM.

Having worked in large corporations, I have to believe that Engineering told them what to say in this regard, and proof read it.
If anyone has any documentation by freescale that disagrees with this, I would like to see it.
Also, if you read the EBs on Flash, if programmed at 25C, it is good for 100K/100 years.

More information:

http://www.freescale.com/files/microcontrollers/doc/eng_bulletin/EB619.pdf
http://www.freescale.com/files/microcontrollers/doc/eng_bulletin/EB618.pdf

This is a good primer on how flash works:
http://www.freescale.com/files/microcontrollers/doc/app_note/AN1837.pdf
Once you start reading this on, you will see it is not as tough as it sounds.



Message Edited by JimDon on 2008-03-14 02:02 PM

[bigmac]

Hello,

The document in question seems to create more issues than it solves -

1)  The flow diagrams within the document seem to perpetuate the "myth" that it is necessary to read FSTAT prior to clearing the FACCERR and FPVIOL error bits, rather than simply clearing the bits, whether they were initially set, or not.

2)  There are a number of instances similar to the following, within the document -

You then need to write programming data to a desired FLASH address. To execute the one-byte program operation, write a hex value $20 to the FCMD register.

After a command is sent, wait at least four bus cycles and then clear FCBEF. Check for error flags and the FCFF bit. If one of the error flags is set, the user must take an appropriate action in the user software. If no flags are set, wait until the FCCF bit is set. This flag indicates that the operation is complete.

I did not expect the phrase "... wait at least four bus cycles and then clear FCBEF".  I might have expected the phrase "... set FCBEF to launch the command, and then wait at least four bus cycles".  Well, that was my prior understanding of the process.

3)  The latter part of the same paragraph, which is also supported by the flow diagram, seems to be saying that the error flags must be tested whilst waiting for the FCCF flag bit to become set.  This may well imply that the FCCF flag may never become set should an error be present.  If this is true, some of the recently posted code examples could enter an endless loop, since they do not test the error flags until after exiting the "wait for FCCFset" loop.

It would seem that a definitive answer is required for the following question -

Following the launch of a flash command by setting the FCBEF bit within FSTAT, does the FCCF bit always eventually become set, irrespective of whether a FACCERR or FPVIOL error occurs?

Regards,

Mac

Message Edited by bigmac on 2008-03-16 07:16 PM

[JimDon]

I quite agree with your summary of the document.

I did not mean to imply nor state that it is a good reference for flash programming, my point was the one paragraph I quoted as being the ONLY statement I have ever found made by freescale as to which parts of the procedure must me in ram.

Amazingly, that one statement is very clear and to the point.

"Steps between command launch and command completion can not be executed out of FLASH. Since a high voltage is applied to FLASH during these steps, FLASH cannot be read properly. Other steps can be executed out of either FLASH or RAM."

While the statement concerning "wait four bus cycles" may not be really necessary, code that does that will work just fine, where as if the statement above is incorrect, the code will not work at all.

That is, the statement quoted is a clear concise, unambiguous statement, where as the rest of the document adds nothing in terms of "facts" - i.e. clear statements of how flash is to be dealt with. As we have seen, while working examples can be handy, they are not a substitute for a clear detailed specification.

Message Edited by JimDon on 2008-03-16 12:32 PM

[bigmac]

Hello,

I re-read section 4 of the data sheet for the QG8, and it now appears that most of the material under discussion closely relates to the contents of the data sheet (as might be expected).  I now think the main point of confusion (to me) was that "clearing FCBF" is synonymous with "writing 1 to FCBF".  Actually, this is counter intuitive for the 8-bit MCU programmer, since very few peripheral flags are cleared in this manner.

The data sheet does not seem to mention the issue of the "4-cycle delay".  However it would seem more plausible for it to occur after the clearing of FCBF, rather than prior, to give time for the FCFF flag to become clear following the launch of the command.  My inclination is not to skimp on this delay, since clock synchronisation issues are potentially involved, between the bus clock and the flash clock.

The flow diagrams shown within the data sheet (figure 4.2) are quite specific that the error flags should be tested, along with the FCFF flag, to determine when exit from the process should occur.  Fortunately, this is easy to do with the "minimalist RAM routine" approach of previous threads, be it with the addition of one extra code byte (the bit mask should be 0x70, rather than 0x40).

Another issue that has been rarely addressed in the recent flash programming threads, is the possibility of COP timeout during page erase, and the need to reset the COP timer during the period while waiting for the FCFF flag to become set.  The page erase period corresponds to 4000 flash clock periods.  For cases where the bus clock is the source for the COP timer,  the calculations reveal that, when short COP timeout period is selected, COP timer reset will allway be required during the erase period.  For long COP timeout period, COP timer reset is essential for bus frequencies of 12.8 MHz, or more.

For "general purpose" flash programming code, I think that COP reset should be added to the RAM based routine, whether or not it is actually needed for a particular project.  The "cost" will be three bytes of RAM for the additional instruction.

Regards,

Mac

[Midas]

Hi Jim,

     Well,thank you for your sharing the hyperlink of 9S08QG quick reference guide

for those friends who are fresh in programming FSL tiny low-pin count but owns powerful peripherial modules.

B.R.

M.Luff