Reply
Posts: 80
Registered: ‎12-27-2016

Sleep during flash erase/programming ?

Since flash erase/programming takes a relatively long time, and since it's current draw is high, I would like for the processor to sleep (EM2) during this time. To wake the micro, we need an interrupt of some sort. It appears as if the flash programming module has an interrupt to indicate that flash erasure/programming is complete, but it doesn't appear as if this interrupt is available to wake the micro from sleep. Is this correct ?

 

I know that LETIMER0 could be used to wake the micro, so I could set the timer for the correct time for either erasing or programming, go to sleep, then wake up for the next action. Of course, I know that for most of the EFM32 micros, this interrupt service routine will have to be in RAM. The ISR can be as simple as clearing the interrupt flag, then leaving.

 

Has anyone done this ? 

 

Thanks.

Posts: 80
Registered: ‎12-27-2016

Re: Sleep during flash erase/programming ?

The reference manual says:

 

"Read and write operations are supported in the energy modes EM0 Active and EM1 Sleep."

 

Current draw in EM1 is not very low (not compared to EM2).

 

The reference manual makes a point to say that the internal oscillators for flash operations are independent from the other oscillators.

 

"An easy to use
write and erase interface is supported by an internal,
fixed-frequency oscillator and autonomous flash timing
and control reduces software complexity while
not using other timer resources."

 

So, if the flash control block is totally independent, then it seems like it should work in any sleep mode (as long as flash is not accessed during erase/programming operations). This is a logical conclusion, but it doesn't match what's said in the reference manual.

 

So the question is still essentially that same with a minor variation - Can flash be erased/programmed in EM2 as long as provisions are made so that flash is not accessed during erase/program operations ?

Posts: 242
Registered: ‎11-17-2013

Re: Sleep during flash erase/programming ?

I would not expect a significant reduction in current - because the flash memory itself needs current to be programmed and erased.

 

You cannot go into EM2 for programming as you need to fetch a new value once a word finished programming.

 

And goning into EM2 while erasing does not save much, as the flash will require more current while erasing.

 

Note that erasing/flashing should not consume a significant amount of battery capacity as there is only a limited amount of flash cycles available.

Posts: 80
Registered: ‎12-27-2016

Re: Sleep during flash erase/programming ?

The problem is mainly with the erase operation which can take up to 40mS. During this time, the micro has nothing to do except burn current waiting for the operation to complete (unless it can sleep).

 

Doesn't the micro core still draw current while the flash is being erased/programmed ?

 

For instance, let's say that the micro was running at 26MHZ with all periherals off. This is 26 x 41uA/MHZ (for EM1) or 1.067mA. THEN, add another 3mA for erase current or 4.067mA total.

 

I could slow the core clock down before I begin the erase which would drop the current loss from the micro down to 275uA (for EM1). At 275uA for the core in EM1, this is nearly 100x the 3.3uA current for EM2.  I would expect the current savings to be significant if I could sleep in EM2 during flash erase.

Posts: 434
Registered: ‎09-18-2015

Re: Sleep during flash erase/programming ?

Hi @gahelton1,

 

Like @Turbo_J said, you are not going to get much reduction in current draw during flash program/erase operations because the bulk of the current is drawn by the flash itself.

 

The best you could do is go into EM1 and wait for the MSC interrupt on completion of write or erase.

 

I don't believe EM2 will work because the MSC register block needs the HFCLK to be accessible. Because the HFCLK does not run in EM2, I don't believe the MSC_IF flags would be updated, and you would not register the necessary interrupts. Our documentation is pretty clear about the high frequency clock trees being disabled in EM2, so while this is not outright a statement that the MSC interrupts will not work in EM2, it is certainly implied.

 

John

Posts: 80
Registered: ‎12-27-2016

Re: Sleep during flash erase/programming ?

Hi John,

 

I apologize if this seems like I'm being stubborn or argumentative, but my application cannot afford to "give away" one extra micro-amp that is not necessary. The reason is because I am running off of a 100uF capacitor during this time, and I can't take anything for granted, nor give any current away.

 

With that being said, I can only assume that whatever the micro draws during flash operations is in addition to the 3mA specified in the datasheet for flash programming and erase.

 

My calculations say that if I can reduce the core clock speed down to 1MHZ, turn off all peripherals, and enter EM1 sleep mode with 275uA micro current draw during flash erase, plus the 3mA for the flash operation, then I can last approximately 48.85mS before power is gone. This is greater than the 40mS flash page erase time.

 

dt = (80uF x (5.5V-3.5V))/3.275mA = 48.85mS.

 

Then I can use the MSC interrupts to wake the micro when the operation(s) are complete.

 

This is the path that I will pursue for now. I'm sure that I will have some questions on how to locate the flash routines into RAM along with the interrupt vectors.

Posts: 434
Registered: ‎09-18-2015

Re: Sleep during flash erase/programming ?

Hi @gahelton1,

 

What device are you using?

 

It may be possible to prescale the HFCLK to further reduce the frequency at which the core runs?

 

BTW, be sure to use the MSC_Init() function and take care with changing the clock. You will damage the flash if you run at a lower clock frequency but do not have the MSC initialized to account for the lower clock frequency because the program/erase cycles will be too long and thus overstress the flash bit cells.

 

John

Posts: 80
Registered: ‎12-27-2016

Re: Sleep during flash erase/programming ?

Hi John,

 

I am using an EFM32JG1B200.

Posts: 434
Registered: ‎09-18-2015

Re: Sleep during flash erase/programming ?

Hi @gahelton1,

 

Since you are using Jade Gecko, you can prescale the HFCORECLK such that the CPU core runs slower.

 

Look at the CMU_HFCOREPRESC register, which lets you set the divide-by factor for the HFCORECLK. This is a digital divider and not associated with the HFRCO/HFXO, so it does not affect the clock used by the MSC.

 

So, you would change the core clock prescaler with...

 

 

CMU_ClockPrescSet(cmuClock_CORE, divfactor);

 

...where 0 < divfactor + 1 <= 512.

 

You can prescale the entire HFCLK domain this same way (via the CMU_HFPRESC register and cmuClock_HF), but that might have some adverse effects relative to the MSC, not to mention that it also messes with the debug clock.

 

John

Posts: 238
Registered: ‎08-16-2012

Re: Sleep during flash erase/programming ?

The MCU core clock should not be less than 1 MHz for flash write.

You can find assert code below in MSC_LoadWriteData() function.

EFM_ASSERT(SystemCoreClock >= 1000000);

My views are my own and do not necessarily represent the views of Silicon Labs
Posts: 434
Registered: ‎09-18-2015

Re: Sleep during flash erase/programming ?

Hi @amenleung,


amenleung wrote:

The MCU core clock should not be less than 1 MHz for flash write.

You can find assert code below in MSC_LoadWriteData() function.

EFM_ASSERT(SystemCoreClock >= 1000000);


That is not quite correct.

 

The CMSIS SystemCoreClock global variable is updated by the SystemCoreClockGet() function.

 

SystemCoreClockGet() calls SystemHFClockGet() to get the HFCLK frequency and divides this by the prescaler set in CMU_HFCOREPRESC.

 

On Jade and Pearl Gecko, there is a separate clock tree branch for the Cortex-M3/M4 clock, and this is a prescaled version of the HFCLK.  So, it is possible to run the HFCORECLK at a frequency less than 1 MHz and still program the flash as long as HFCLK >= 1 MHz.

 

@gahelton1 could set HFCORECLK to something like HFCLK / 50, so if HFCLK = 1 MHz, HFCORECLK would be 20 kHz and the cycle time would be 0.05 ms. Assuming a maximum of 40 ms for the MSC erase interrupt flag to set, the 12 clock cycles for entry into the IRQ handler would be 0.6 ms, leaving plenty of time for @gahelton1's code to do whatever it needs to be before the system loses power.

 

John

Posts: 434
Registered: ‎09-18-2015

Re: Sleep during flash erase/programming ?

Hi @gahelton1,

 

It just occurred to me that what I wrote above may not matter much.

 

Your only real option is to wait in EM1 for the MSC erase interrupt.  This is the lowest power option available as it shuts off the HFCORECLK and leaves the HFPERCLK running to any enabled peripherals.

 

We've already established that you cannot wake from MSC interrupts in EM2 because the HFCLK is shut off in EM2.

 

So, your initial calculations figuring 48.85 ms of run-time still stand.  Your best option is to do whatever software and peripheral shutdown tasks are necessary as fast as possible once you've kicked off the flash erase and then go into EM1.

 

You could see if there is some marginal current savings from switching the HFRCO to 1 MHz so that the HFCLK is 1 MHz, but remember this has to be done before you call MSC_Init() and start the erase. Given that any shutdown tasks you'd be running concurrently with the flash erase would take longer to execute, your current draw might be higher than if you simply keep the HFRCO at whatever frequency you usually run at and get your shutdown tasks out of the way faster so you can get into EM1 sooner.

 

You could experiment with both options, but I'd be surprised if there is a difference that matters one way or another.

 

John

Posts: 80
Registered: ‎12-27-2016

Re: Sleep during flash erase/programming ?

Hi John,

 

After I have started erasing a flash page, and before I go to sleep (EM1), I change the CMU_HFCOREPRESC = 31 (divide by 32) to set the core frequency to 1MHZ. Also, the HFPERCLK is turned off.

 

After the MSC interrupt wakes the micro, HFCOREPRESC is set back to 0 (divide by 1) for full 32MHZ core clock, and the HFPERCLK is turned back on.

 

Everything seems to be working as expected.

 

Thank you for you help.

 

Next, I think that I will open a new topic on flash programming/erase cycles and the number of times that a flash word can be programmed without erasure (for an application that simulates byte sized EEPROM data storage). Although it has been discussed before, it is one of those subjects that is sure to stir up a brouhaha.

 

 

Posts: 434
Registered: ‎09-18-2015

Re: Sleep during flash erase/programming ?

Hi @gahelton1,

 

Next, I think that I will open a new topic on flash programming/erase cycles and the number of times that a flash word can be programmed without erasure (for an application that simulates byte sized EEPROM data storage). Although it has been discussed before, it is one of those subjects that is sure to stir up a brouhaha.

 

There's no discussion to be had about this. As our documentation makes clear, you may write a flash word twice between erases so long as bits that are not to be changed are kept at 1 when the second program cycle is run.  You cannot walk a 0 through a flash word with multiple program cycles in violation of the erase rule or you will overstress and damage the underlying flash bit cells.

 

John

Posts: 80
Registered: ‎12-27-2016

Re: Sleep during flash erase/programming ?

John,

 

I was referring to Section 3.1 of AN0019 when I was talking about "Byte" sized data for EEPROM simulation. However, I suppose that the byte sized variables in AN0019 also included a byte sized virtual address. In this case, the data and the virtual address would be concatenated into one 16 bit value for the purposes of writing to word of flash. Therefore, only two writes to a word would be needed for the 16 bit data/address value.

 

For my application, I don't need a virtual address, and my data is only 1 byte, so I will be wasting two bytes of every word. To get the required number of operations, I will have to double the number of pages used, but if that's how it has to be - then so be it.

 

Now, I want to clarify flash life. Do we still get 10K pages erasures (or 20K depending on the part) ? In other words, does the two writes to each word affect the flash wear-out characteristics ? It would seem that it wouldn't, but the flash in these devices may be different than other devices. Certainly, this could be something that varies from manufacturer to manufacturer, and even part to part.

 

After reading many white papers on failure mechanisms for flash, I suspect that the failure mode of multiple programming of the same word is not a wear-out mechanism, but a failure mode where a nearby bit cell is unintentionally programmed by leakage currents. This mechanism is probably more likely at higher temperatures. Of course, all of this is speculation on my part.

 

 

 

 

Posts: 434
Registered: ‎09-18-2015

Re: Sleep during flash erase/programming ?

Hi @gahelton1,

 

Now, I want to clarify flash life. Do we still get 10K pages erasures (or 20K depending on the part) ? In other words, does the two writes to each word affect the flash wear-out characteristics ?

 

The rated W/E cycle lifetime is the number of writes followed by erases.  The two allowable writes per word is incorporated in this.

After reading many white papers on failure mechanisms for flash, I suspect that the failure mode of multiple programming of the same word is not a wear-out mechanism, but a failure mode where a nearby bit cell is unintentionally programmed by leakage currents.

 

It can be a write disturb mechanism but the bigger concern is over-stressing of the flash cells.  In cases of customers who run into flash reliability issues, we have determined in several cases that their problems are due to application of program or erase voltages beyond what is allowed for the flash because a reset occurs during a write or erase routine.  Multiple applications of the programming voltage to the same bit cells falls into the same category, thus the two write limit.

 

John