Flash write optimization

Your objective is out of my "sweet spot" (small that) yet perhaps our efforts w/other vendor ARMs aids.

a) Might your use of 120MHz system clock cause the insertion of "wait states" which may be avoided by (counter intuitively) dialing down (slowing) your system clock?

b) Might larger size data packets reduce the time overhead associated with such transfers?

c) Or might a, "best transfer size" exist - awaiting your recognition?

You note a, "10 to 1" time variation to write 8 bytes of data.  Is that info supplied w/out further description or detail?  If so - might your construction of different experiments aid in your discovery of "how" the fastest write times are achieved?  In theory (hopefully, at least) this optimization would "carry over" to those transfers beyond 8 bytes in size.  In our experience - it's often easier to detect how to best SLOW your transfer - not speed it!  (thus you avoid those factors in your implementation - long ago I gleaned this method in college chem. lab...)  (also learned to run - fast - as lab filled w/smoke...)

Finally - can you monitor the time taken to transfer every 32KB or 64KB - so that you can detect the uniformity of transfer rate - throughout your extended data transfer?  (i.e. perhaps the transfer rate declines as the transfer size increases.)

Hello Suresh,

I think there is a critical piece of information missing in the computation. That is the programming of the code which is being done by an IDE will happen over a debug interface like JTAG or SWD. These interfaces are slower. Typically in the range of 100KHz to a few MHz. These at the same time are serial interface and the overhead is substantial. Also the IDE environment will implement some form of ACK system to ensure that the 8 bytes programmed have been accepted before the next 8 bytes are written. Finally a verify operation to ensure that what has been programmed matches up with the actual bin image on the PC side.

So even when assuming that a fresh out of factory part with 30us programming time is used, the time to program 480KB code would be way more than 1.8s. You would have to see what all operations can be got rid of. One of them would be Verify operation of the entire image (assuming you trust the IDE to a flawless job and device operating conditions are not affected during the operation).

Regards,
Amit

Hi Amit,

Our posts just crossed (again) and I confess I read, "write flash" as being outside of the IDE - instead being done by the MCU under MCU program control.  My sense is that the IDE - as you describe - would be used to "program" flash - not simply "write flash."  (i.e. MCU needs to store processed data w/in flash memory - while operating stand-alone.  (No IDE connected))

Thus poster is gifted w/2 approaches - yours via skill & inside info - mine not much beyond (some) logic & SWAG...

Hello cb1

I agree with your inputs on interpretation of Application and Write Flash.

We normally refer to write flash as program (irrespective of the IDE or Application). Application is also a very lose term: some of call IDE/Programmer an application while some use MCU code as Application.

It could be a nice idea to have the poster clarify. But either ways I would not have put your view as my line of thought so indeed this is a nice post response(s)

Regards

Amit

Hi Amit, cb1,

                         Thanks for your reply. I really appreciate your quick response and sorry for the confusion. When i said flash write, iam copying flash from one location to another using FlashProgram API. I tried writing different block sizes at a time(16KB, 32KB, 480KB) and observed little improvement(1 or 1.5 sec) overall, but finally it comes about 8-9 seconds.

I found the flash program timing info in Tiva C data sheet, but didn't find any speed optimization techniques or info.

Regards,

Suresh

Let the record show - even "blind squirrel" (occasionally) blunders across a walnut.  (i.e. cb1 "diagnosis" proved correct)

Amit knows (or can best access) the fine details you need - my post detailed "how" you may potentially "tease out" such info - in absence of factory "inside knowledge."

And thank you for clarifying w/such good detail - and so quickly!

Hello Suresh,

Is the code execution happening out of Flash as well? As mentioned by cb1 the code execution may be delayed by wait state the code crosses the prefetch buffer size. To avoid the same, one way would be drop down to 16MHz where the flash is at speed access. Also code execution is stalled when code execution and Write is happening in the same bank-pair. You may want to switch write operation to another bank pair. This will allow you to read the data to be copied into the other bank-pair while Program operation is happening allowing read-program to be pipelined.

Hello cb1,

Recorded... and much appreciated.

Regards

Amit

Hi Amit,

           I will reduce the CPU clock speed and will calculate the time to program flash write and share my observations with you. The code executing the flash write is in separate memory bank. Basically i am copying my firmware from upper flash region to lower region(to do firmware upgrade) keeping a firmware swap execution code in separate memory bank which we are not overwriting.

One more trial what i am planning to do is to set FMME bit in FLASHCONF register to copy upper 512KB memory region to lower 512KB without using my firmware swap code. Not sure how much time this takes to copy the firmware.

Regards,

Suresh

Unstated in this thread is the, "How, why, where - or if" user's may achieve the fastest flash transfer rate!  Again poster has noted a 10:1 range (documented via spec insert) - yet that fact has passed w/out mention - and is not that of some importance? 

Is operating @ 16MHz - and transferring from a separate memory bank - "all that's required" to obtain the greatest transfer speed?  Seems that this, "order of magnitude" rate variation deserves some detailing...  (as a specific "horror" I've read that both MCU temperature, flash size and flash aging all may impact transfer rate - thus may explain the 10:1 spec "vagueness."  This info gleaned from a variety of ARM & flash memory readings - not specific to this vendor)

Should this data not be in vendor's, "secret knowledge stores" the use of 8 byte data transfers - under multiple, carefully chosen (and recorded) source/destination & clock rates - may aid in discovery.  Use of such small, 8 byte transfers provides the fastest means for users to write code to "automate" such testing - having the MCU "time & store" the results of each test iteration.  Should rate variation be noted - users should then alter the transfer size (gradually) and repeat such tests - to determine "if" transfer size impacts the earlier (8 byte) flash transfer rate findings...

suresh reddy2 said:

I will reduce the CPU clock speed and will calculate the time to program flash write and share my observations with you. The code executing the flash write is in separate memory bank.

If so, as already noted FlashProgram executes from flash and will suffer flash wait states at high CPU clock speeds.

As an alternative to reducing the CPU clock speed, try using the ROM_FlashProgram function in the TM4C129 ROM. I think the ROM runs as zero wait states, so may give faster flash programming times.

Use of the ROM's functional equivalent call surely merits a try - unless/until vendor supplies "insider flash info" - this reporter's (repeated) suggestion to conduct carefully designed "experiments" remains, "atop the pack" to decode that 10:1 (unexplained) flash write variation...  That's a major curiosity - missed by all others (still) - which concerns!

As both "source & destination" reside w/in flash memory - and it is the flash memory which impedes transfer speed - the call to ROM may not yield significant improvement.  (suspect that individual "flash access" will dominate code execution time)  Yet - on the whole - worthwhile - although it's reasonable to conclude that "should" the ROM call offer great improvement - that fact should be adequately highlighted w/in MCU manual!  (otherwise - users are lured into the famed "PF0/PD7 poorly marked trail" endless trap...)

Experiments may not be hard to set-up - although the ROM calls may see "diminishing returns" as the size of the transfer lengthens...  In such case - the earlier suggested 8 byte transfers may provide less than "Stellar" value...

[edit 08:46 CST] dawns that the 10:1 (unexplained) transfer rate variation may "enable" vendor production process change - either for/against humble users.  Clear explanation of that 10:1 eliminates the need to "guess."

cb1_mobile said:

(as a specific "horror" I've read that both MCU temperature, flash size and flash aging all may impact transfer rate - thus may explain the 10:1 spec "vagueness."  This info gleaned from a variety of ARM & flash memory readings - not specific to this vendor)

Cell degradation as a function of erase cycling results in a gradual lengthening of the time required to complete an erase or program operation. Sectors with relatively infrequent updates will not experience significant lengthening of erase or program operations. Individual sectors which are frequently updated can be expected to experience up to 400% increase in sector erase times and up to 200% increase in programming times over the life of the device.

I haven't yet found an equivalent report for the flash used in the TM4C129 series, but for C2000 devices found http://processors.wiki.ti.com/index.php/C2000_Flash_Common_Issues/FAQs#Max_Erase_Timing which says:

The Erase operation is a dynamic operation - pulses are applied until the erase is complete or the maximum number of pulses is reached and the erase fails. Thus the amount of time it takes to erase will vary per attempt and per sector. It will change at different temperatures, and in addition it will also change with ‘the number of previous erase/program cycles’ (flash endurance). Hence, it will also change from part to part. The system related issues/parameters (supply voltage, ripple/noise etc) will be on top of this. This will change with temp as well as during the lifetime of the flash.

In summary, the erase function of the different flash sectors is a highly dependable process. It depends on temperature, silicon age, number of previous erase steps, amount of flash used, etc. Therefore it is nearly impossible to predict a specific maximum timing for erasing flash sectors. If everything possible went to its absolute max, the MAX erase time would be extremely long. This can vary from chip to chip and is not characterized. Typically you will see a few seconds per sector to erase.

Glad that we (at last) find area of agreement.  And kudos to you for "digging out" the detail - I encountered long past.  Your efforts reveal you to be "top notch" investigator - that's so often critical - and great that you (so often) share here!

While likely those same flash mechanisms operate here - would be "nice" for vendor to (somewhat) explain/detail - and provide some quantitative analysis.

From your detail of, "400% increase in sector erase times" and "200% increase in programming times" (might that yield an 8:1 "predictable" life flash time degradation) vendor's 10:1 figure appears to offer some "boundary" protection.

All that said - poster still seeks to achieve fastest flash writes while part is new/young!  Thus "lifetime aging" seized/presented here first by me - then you - may not fully/properly answer poster's issue.  Hope remains that your suggestion of ROM call - or my suggestion of critical/methodical experimentation (or both) may "unlock" the "secret" of fastest, "flash to flash" transfer.  (why this is held secret/hidden - far beyond this reporter's pay grade...)

Appears we're left w/experimentation or vendor's "inside knowledge" and that the 10:1 concern may be (primarily due to use/aging).  Or not - we should not be left to, "guess!"

@ Amit - is it not fair that poster Chester - et moi - receive humble Verify for effort & originality of thought?

Hello cb1,

I would love to tick the Verify once I can suitably post an update on a fresh device with the same kind of operation that the poster has mentioned. In fact Chester's post from C2000 devices is almost what basic flash is made up of and TM4C devices are no exception for this rule.

Regards

Amit

Chester Gillon said:

As an alternative to reducing the CPU clock speed, try using the ROM_FlashProgram function in the TM4C129 ROM. I think the ROM runs as zero wait states, so may give faster flash programming times

FlashProgram and ROM_FlashProgram are timed writing a 480K buffer from the low flash region to the high flash region.

An example output is:

[Sun Nov 9 22:19:36] Verified 491520 bytes of data at flash address 0x8000
[Sun Nov 9 22:19:36] ROM_FlashErase of 491520 bytes took 20 milliseconds
[Sun Nov 9 22:19:46] ROM_FlashProgram of 491520 bytes took 9041 milliseconds
[Sun Nov 9 22:19:46] Verified 491520 bytes of data at flash address 0x88000
[Sun Nov 9 22:19:46] FlashErase of 491520 bytes took 56 milliseconds
[Sun Nov 9 22:19:52] FlashProgram of 491520 bytes took 5695 milliseconds
[Sun Nov 9 22:19:52] Verified 491520 bytes of data at flash address 0x88000
[Sun Nov 9 22:19:52] ROM_FlashErase of 491520 bytes took 56 milliseconds
[Sun Nov 9 22:19:58] ROM_FlashProgram of 491520 bytes took 5696 milliseconds
[Sun Nov 9 22:19:58] Verified 491520 bytes of data at flash address 0x88000
[Sun Nov 9 22:19:58] FlashErase of 491520 bytes took 56 milliseconds
[Sun Nov 9 22:20:04] FlashProgram of 491520 bytes took 5694 milliseconds
[Sun Nov 9 22:20:04] Verified 491520 bytes of data at flash address 0x88000

suresh reddy2 said:

In the datasheet, it is mentioned that it takes from 30us to 300us to write 8bytes of data. According to these numbers my flash write should take 1.8 seconds to 18 second

Hi cb1, Gillon

            Thanks for your inputs. I tried writing individual 8bytes of data to flash, but as such didn't observed any improvement. I tried using ROM APIs for flash erase and program, didn't observed much improvement. I just want to know is there any possible/known ways to flash write speed improvement.

Regards,

Suresh

Hi,

I do not know why do you try to write only one byte at the time - since the flash is organized on 32 bits words and the programming registers are 32 bits wide, then the natural choice is to program four bytes at the time (this works since the old Stellaris family). More, as the user manual states, there are 32 registers for buffered writes, so you can program 32 words at the time (I did not tested that) - but you can try such thing.

Petrei

cb1_mobile said:

I've suggested specific 8 byte transfers to "test/glean understanding"

And another cb1: "How or even "can" one achieve the 30uS, 8 byte, flash-write time as listed w/in MCU manual?"

I've suggested 8 bytes as that's what the MCU manual claims, "May be achieved w/in 30uS!"  Aging cannot impact so new/fresh a device.

I believe the "real issue" remains, "How or even "can" one achieve the 30uS, 8 byte, flash-write time as listed w/in MCU manual?"  Aging - as 1st reported by me (here) plays no factor in an essentially brand-new device. 

Is that 30uS just, "Specsmanship?"  (some makers are guilty of just that)

Poster reports call to ROM function (as I earlier posited) led to little improvement.  Clearly then - "How, where, when" did factory achieve their 30US, (they did achieve that - right?) 8 byte flash write?" 

Hi Amit,

           Thanks for the analysis. I used the same code and tried on my Tiva board and it showed around 1second. I will explore more and will let you know my observations.

Regards,

Suresh

Hello Suresh,

Looking forward for the data and results from your testing

Regards

Amit

Suresch,

What's exactly the marking on the MCU part you'd mentioned? What is its revision?

Amit,

With the sole purpose to demonstrate appreciation of your efforts. I was able to execute your code on two EK-TM4C1294 Launchpad boards. One of them is of rev. C while the other is of rev.D. Both are populated with pre-production parts (XM4C1294NCPDTI23BATY5W and XM4C1294NCPDTI243A4Q4W respectively, to be precise). The code prints:

Rev.C board, 3 attempts:

Start Time=13
End   Time=141544700

Start Time=13
End   Time=141449828

Start Time=13
End   Time=141450404

Rev.D board, 3 attempts:

Start Time=13
End   Time=145037228

Start Time=13
End   Time=145003082

Start Time=13
End   Time=144978260

That's a raw data and I'm too lazy to calculate the timings (sorry) because

All,

Seems I missed the meeting so could you explain what's the objective for such benchmarking? The process takes as long as it takes and that's fine unless the mfg-specified MAX value for the time interval is exceeded. No?

---

regards,

    Igor

Hello Igor,

The values returned is the indication of the time it takes for Program of erased 64KB of Flash.

Time = (EndTime-StartTime)/120MHz

In this case it is 1.2sec

Regards

Amit