EEPROM on MC9S08DN60

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

EEPROM on MC9S08DN60

3,209 Views
Encoder
Contributor I
MC9S08DN60 data sheet rev.2 is at least ambiguos when refering on EEPROM. I would expect EEPROM was a storage area which could be programmed from everywhere in the main program in flash without any special care other than some precise timing and possibly continuing making other tasks during programming, i.e. simple interrupt servicing, like I did on the venerable 68HC705CB16.
 
From what I discovered by a careful reading of chapter 4 of the data sheet, there is no evidence of difference from the main FLASH memory: EEPROM and FLASH are essentially the same and they require the same programming and timing. The sector sizes are different 8 vs. 768 bytes, hence there is more granularity on erasing but the time to erase a small 8 bytes sector and a larger 768 one is the same: i.e. 20ms minimum, nominal. A small advantage is that only 20 to 45us plus some overhead is needed to program an EEPROM cell compared to 10ms of the old 705B uC.
 
Nowhere in that chapter I read that FLASH must be programmed only from RAM like it is on the others 9S08 families without EEPROM. Can I resolve that FLASH and EEPROM as present on 9S08DN are separate pages of FLASH, with different sector size and they may be programmed each from the other without relying only on RAM?
In that case I can put some basic FLASH program routines on EEPROM avoiding to copy everytime them on RAM and I can perform EEPROM operation smoothly from the main program on FLASH with program routines also on FLASH.
 
In my case perhaps the write process is not so disturbing but I cannot wait for at least 20ms to erase an 8 byte sector: I need to do some other tasks in the meanwhile. If this is not possible I will be forced to use external EEPROM but this does not seem to be reasonable to me: why in fact declare EEPROM on the uC if this is not simply accessible from main program?
 
In conclusion may someone of you guys answer to:
  1. EEPROM may regularly be written and erased just from routines on FLASH and these routines (specially the long erase ones) may be interrupted
  2. Precise timing of write and erase routine is not required: either FLASH and EEPROM are managed by an hardware state machine which relies only on the precision of the flash clock: as soon as the required process time has expired, the program charge pump is automatically turned off.
  3. FLASH may be programmed even from EEPROM area in addition to RAM
  4. Is there some unambiguos official Freescale document I missed which explains these subject specifically on the 9S08DN series? I was able to find AN2156 and AN3404 but these are not pertinent to the 9S08DN nor there is anything on EEPROM on the cited HCS08RMv1 HCS08 Family Reference Manual vol. 1

I rely on you guys! :smileywink:

Encoder

Labels (1)
0 Kudos
7 Replies

579 Views
Ake
Contributor II
Hi,
On the 9S08Dx series there is both EEPROM and Flash EPROM.
As the clever reader, you have discovered that it is the same kind of memory behind those two words.
The algorithms for erasing/programming the two memories is the same.
The difference is that the memories are divided into sectors, where the Flash part has 768 byte and the EEPROM can be either 4 or 8 byte sectors.
 
The Flash and the EEPROM are totally independant of each other. So it is quite easy to erase/write something in the EEPROM. The same thing applies to the Flash EPROM, but you must be sure that you have put the erase/programming code in the EEPROM.
 
If the EEPROM is full of variables, the classic solution with the code copied into the stack of RAM should be used. Ofcourse you can use static buffers to store the RAM copies in, but it takes some valuable space.
 
Why does it take 20 mS to erase either a 768 byte or a 4 byte sector?
I think that the EEPROM is much faster, but that when  building the hardware, the one time solution turned out to be simpler.
 
As all timing is handled by built-in logic, it is quite simple to run and debug the code. You can single-step thru all the code without beeing afraid of burning up some memory.
 
But, remember that when erasing/programming the Flash EPROM, interrupts are not allowed.
If an interrupt is running it will destroy the data that is stored in the Flash EPROMs input buffer.
 
Regards,
Ake
0 Kudos

579 Views
Encoder
Contributor I
Thanks Mac and Ake.
You confirm my doubts on the subject: if I cannot interrupt the EEPROM long erase procedure I may be obliged to have some external EEPROM.
I am already able to use FLASH as EEPROM on 9S08AW60 with excellent results, but there always is the 20-25ms black hole during erasing, while writing is faster, expecially using the sequential write command.
 
Perhaps some other small differences may justify the little price boost of 9S08DN vs. my long beloved 9S08AW:
- The more efficient variable data storage due to the 8 byte sector of the so called "EEPROM"
- The possibility of performing storage in memory from either Flash or EEPROM insted of playing from Ram only.
- The 12 bit ADC
- The better clock generator which may use a more precise PLL instead of the noisy and inaccurate FLL.
 
If I have some additional facts after some experiments with my MC9S08DZ demo board, I will report here.
 
Bye,
Encoder
0 Kudos

579 Views
Ake
Contributor II
Hello,
It seems I did not explain how  the Flash EPROM/EEPROM memory works:
 
If the EEPROM is erased/written, the data and address buses connected to the EEPROM must be stable.
The same applies to the Flash EPROM.
 
But if interrupts are used, the interrupt vectors will be used, and they are high up in memory.
This means that if an interrupt occurs while the Flash EPROM is erased/programmed the operation is disturbed and the result is not what would be expected.
So the interrupts must be disabled while the Flash EPROM is changed.
 
For the EEPROM there is no such restriction. Interrupts may run in the middle of an erase/program operation without problem. You can have an OS that does a task switch in the middle of an erase/program operation without any problem. All the critical timing is taken care of by the hardware. The only restriction is that the interrupt routine should not use the EEPROM.
 
The big advantage of the EEPROM/Flash EPROM vs Flash EPROM memories, is that on the Flash EPROM memory, you must copy the routines to RAM and run them there.
You must also be very careful on how the Flash EPROM protection bits are handled.
The sector size is much larger in the Flash EPROM than in the EEPROM, which makes it more difficult to update non-volatile data, where the power might disappear in the middle of the operation.
 
Hope this cleared some questions.
 
Regards,
Ake
  
0 Kudos

579 Views
kef
Specialist I


Ake wrote:
But, remember that when erasing/programming the Flash EPROM, interrupts are not allowed.
If an interrupt is running it will destroy the data that is stored in the Flash EPROMs input buffer.

Ake, as far as I know flash and eeprom are not readable while being programmed. s08/s12  interrupt vectors are by default in flash and that should explain, I think, why interrupts should be disabled for flash programming time. CPU just couldn't fetch valid interrupt vectors and will jump into the weeds on first interrupt.
 
Regards


Message Edited by kef on 2008-01-24 09:11 PM
0 Kudos

579 Views
Encoder
Contributor I
If Kef is right (vectors are surely resident in flash) there is the possibility that Flash writing cannot be interrupted but EEPROM could be.
 
That which was also an initial hypothesis of mine, may be enough for me. I hope I will test it in the near future.
 
Regards
0 Kudos

579 Views
allawtterb
Contributor IV
As pointed out above, you can interrupt the programming of EEPROM to run other tasks.  I had orginally turned off interrupts on a DZ60 while writing to EEPROM but had a product that required interrupts to always be on(Detecting a zero crossing for controlling a Triac). 


Message Edited by allawtterb on 2008-01-24 10:24 PM
0 Kudos

579 Views
bigmac
Specialist III
Hello Encoder,
 
My preliminary copy of the data sheet certainly is ambiguous.  My understanding is that, unless the flash and the EEPROM reside within separate flash arrays, there would be no EEPROM programming using flash resident code.  This is because the whole array is disabled during the erase or programming process.
 
Paragraph 4.5.3 of the data sheet mentions "FLASH or EEPROM array", as though they are separate arrays.  But loose wording cannot really be ruled out.  Additionally, within section 4, there appears to be no warnings given for any flash programming limitations - I might expect that explicit warnings should be given if such limitations exist.
 
If you need to avoid the 20ms sector erase period, I guess the sector would need to be "pre-erased" when timing was less critical.
 
If you require many EEPROM sectors for non-volatile data, it might actually be more efficient to use a single flash sector for the purpose.  You then need to allow the erase period for a single sector only.
 
Regards,
Mac
 


Message Edited by bigmac on 2008-01-24 01:52 PM
0 Kudos