Code execution(Address Bus And DATA Bus Access) during FLASH Erase HCS908

[Denn]

Hello All,

In HCS908AW32, We have an flash erase time of 20 ms for a single page of 512bytes.Single page (512B) is the minimum possible erasable flash area.I cannot erase anything less than this num of bytes.

Now my doubt is that during this erase time (i.e. after the erase command has been issued) for the next 20 ms should I wait there indefinitely till FLASH Command Complete Flag is SET or can I do anything useful like executing some critical code.

If I wait till 20ms some of my critical code could not be executed(to be frank some data coming from outside into the micro) I'll miss this event.

Is the address/data bus locked during this period? If not Then I think I can execute code from RAM.(Code cannot be run from flash while flash erase/programming are to be done right? )

Also I have noticed sometime back while flash erasing/programming, an  access to the flash part of the code creates reset in HC908GR32.But in HCS908AW32 if I access the operation was getting affected.

AW32 data sheet documentation is really poor. Have anyone had previously run any code during this erase period  or any valuable suggestions for me ???

Best Regards,

Denn

[peg]

Hello,

---

Denn*** wrote:

Now my doubt is that during this erase time (i.e. after the erase command has been issued) for the next 20 ms should I wait there indefinitely till FLASH Command Complete Flag is

---

Well its not actually indefinitely, it will be something like 20ms or its hung.

---

Denn*** wrote:

Is the address/data bus locked during this period? If not Then I think I can execute code from RAM.(Code cannot be run from flash while flash erase/programming are to be done right? )

Also I have noticed sometime back while flash erasing/programming, an  access to the flash part of the code creates reset in HC908GR32.But in HCS908AW32 if I access the operation was getting affected.

The address/data bus is not locked, it is up to the programmer not to make any FLASH accesses during this time. If you do access flash then the result is not defined, possibly a reset, possibly erasing where you did not expect etc etc.

---

Denn*** wrote:

Now my doubt is that during this erase time (i.e. after the erase command has been issued) for the next 20 ms should I wait there indefinitely till FLASH Command Complete Flag is SET or can I do anything useful like executing some critical code.

If I wait till 20ms some of my critical code could not be executed(to be frank some data coming from outside into the micro) I'll miss this event.

---

I would assume that given enough RAM, then yes you could run a routine there in order to process incoming data, write it to a buffer etc while you are waiting for the erase to complete.

[Denn]

Hi Peg,

Thank you for your speedy reply.

Actually the info to the MCU was coming through an interrupt.Isn't  it ok that I execute the ISR from RAM.

Does interrupt create a problem while erase is in progress ?? If it does then I will be left with only one option.i.e. to poll for the event flag and disable "interrupt enable flag" and execute the code.

Regards,

Denn

[peg]

Hi Denn,

You're out of luck there.
Interrupts need to fetch the vector from flash and this is forbidden.
Polling it is.

[Denn]

Hi,

I'm out of luck that is for sure.....Yes you are right I cannot afford to have interrupts!!!!

 I was thinking of polling the event(ISR) flag and then execute the ISR code( ISR code will be copied to RAM by making it as relocatable code).But problem is that I have the RAM space of 2k and the associated function calls for processing this critical data is little less than 2k and I cannot copy all these functions there..... RAM space shortage..

2) Not only that worst thing is that atleast two critical data will be coming to MCU during this erase period. If this was one atleast we could have stored the imp data in a buffer (to offset copying all fn to RAM )and then execute from flash after this 20 ms.Anyway I'll miss one critical data...It'll impact my system

[bigmac]

Hello Denn,

If your ISR code is approaching 2K in size, this is suggestive that your ISR is far too complex, and you are executing code that should optimumly be done outside the ISR.  Typically, ISR code should take only a few microseconds to complete.

Assuming that there are periods during the operation of your code when a 20 millisecond wait would not be critical, a possible approach is to "pre-erase" one or more flash pages at a non-critical time.  Since the write period is much shorter than the erase period, this will probably not represent a problem to your critical code.  But you might need to avoid using burst programming mode.

If this is not possible, you will need to consider use of a different MCU type containing separate EEPROM flash for data storage, or alternatively, an external serial EEPROM device.

Regards,

Mac

[Denn]

Hello Mac,

---

bigmac wrote:

If your ISR code is approaching 2K in size, this is suggestive that your ISR is far too complex, and you are executing code that should optimumly be done outside the ISR.  Typically, ISR code should take only a few microseconds to complete.

ISR code calls some some functions And this functions are really necessary for the speedy response of for this message.Highly critical! And response should be within 3-4ms  ... You can call it is a lengthy ISR since its calling functions within itself. We have to do this inorder to avoid delay in the application response (also MCU response).Protocol based ISR!!!

---

bigmac wrote:

Assuming that there are periods during the operation of your code when a 20 millisecond wait would not be critical, a possible approach is to "pre-erase" one or more flash pages at a non-critical time.  Since the write period is much shorter than the erase period, this will probably not represent a problem to your critical code.  But you might need to avoid using burst programming mode.

---

What is this period concept??

And preerase at non critical time is not feasible. Because I am using the concept of eeprom emulation of flash.So I write small chunk of imp bytes say 10 at a single time.Then when I need to store new values I increment the block(=10 bytes) counter by 10 untill I reach 512 bytes.Then finally I erase the entire page(512B) that is at run time and then continue writing chunks of 10 bytes.(During runtime there is certain requirement that forces one to store in flash (imp data)

And hence preerase at non critical time is not feasible.If I erase at startup before entering into say, infinite- loop then i'll be risking the life of flash memory unnecessarily (10000 erase typ )

 And Burst programming is not used.Its byte programming

---

bigmac wrote:

If this is not possible, you will need to consider use of a different MCU type containing separate EEPROM flash for data storage, or alternatively, an external serial EEPROM device.

Hardware designs are FREEZED !!!! MCU is HCS908AW32

Regards,

Denn

Message Edited by Denn*** on 2008-03-06 09:07 AM

[peg]

Hi Denn,

Hmmm...... period - from the dictionary "a portion of time" this seems to me to fit exactly with what Mac means.

It would seem to me you are really battling here. 2k of code could approach half a millisecond to execute. With the things that need to be done that you have told us about there appears little time left over for the things you haven't.

[Denn]

Hello Peg,

I really don't know what to answer you.  

And I'm not battling with you guys but with the problem I have!!!

If you ask me what is period now I would say in SIGNAL context : The complete duration of signal before it repeats.

TASK context: Again The complete duration of task before it repeats. and so on...

Since we think interms of embedded and signals, these kind of terms sometimes takes us to more specific meaning in particular field rather than day to day meaning.I am really sorry if I gave you guys that feeling

Ya, you are right the code of 2k could be executed well around 0.5 ms. But problem is with the RAM shortage. Only solution is to optimize the reqd code as much as possible.

Regards,

Denn

Hi Mac,

Is your period term same as what Peg suggested or anything that could be useful to me.

Regards,

Denn.

[peg]

Hi Denn,

I never meant battling with forum users just you battling with your task given the available resources.
If you can't change the MPU, can you add say a FRAM to get this done. It is no good trying to use the "flash as eeprom" trick if it compromises the original intended function of the MPU.

It is easy to first think of the specialist meaning of a word when it is in that special context.

Take "broadband" for example, it used to be an adjective and used only in a technical context, now it is mainstream it has somehow morphed into a noun.

[bigmac]

Hello Denn,

It seems that you have ruled out all possibilities except the external EEPROM approach.  My personal choice would be to use a serial EEPROM with SPI interface, rather than IIC type, as Jim D suggested.  The SPI interface is faster and simpler.

If write endurance is an issue, I might alternatively consider a FRAM device.  These also have the advantage that writes are as fast as reads.

If your critical interrupt processing takes a substantial portion of the available processing time to complete, this does mean that any other interrupts, that may be necessary, will mostly be delayed until the critical interrupt completes.  Their ISRs must be very short so as to have negligible effect on the next critical interrupt that they may possibly delay.

It is also possible that the use of any other interrupt may be impractical, in this case.  For the circumstances you have outlined, I think you will need to become aware of the exact worst case ISR processing period, which should also include the amount of delay that all other ISRs may introduce.

A final suggestion if you are programming in C - if the critical ISR code should contain any switch statements, replace these with if / else if constructs for faster code execution.

Regards,

Mac

[JimDon]

Well the DZ has a Sector Erase Abort command that lets you erase quickly, but the AW does have that command, so you are out of luck there.

macs idea about an external EEPROM device is a good one.

AT24C512B is a great choice - 64kx8 - low cost, no erasing, single byte write or it will buffer up to a128 bytes.
I2C Interface. very easy to use, small footprint.
Of course you can do all this will interrupts are on.