GDB support for Flash memory programming

Steven Johnson <sjohnsonsakuraindustries.com>
writes:
>>That's a good point.  It's important for the
interface to allow
>>efficient implementations; performance is part of
the user interface.
>>If everyone hacks around it because it's slow, then
we haven't
>>contributed much.
>>
>>In your experience, on modern devices, what's the
longest it takes to
>>copy a sector of flash to RAM?  
>>
> Well, its a memory to memory copy, so it will take as
long as any memory
> to memory copy.  That will depend on the speed of the
Flash, Ram and CPU
> Bus, and width of each device.  That isn't really a
problem, for devices
> with enough memory to back up the page "In
Ram" the extra time to backup
> copy wouldn't be a lot, in comparison to the
programming time.  The
> issue is systems without enough memory, then you are
talking memory read
> speeds thought the debug interface.    In Practice, the
overhead is
> probably like this:
>
> A Spansion S29GL128N NOR with a 128K Page and 8 bit bus
(Writing that 1
> page):
>
> 1. Read 128K (128K Read Cycles over the Jtag Bus)
> 2. Erase Page (0.5 - 3.5 seconds, excluding time to
auto-preprogram all
> bits to 0)
> 3.1 Write Byte (4 write cycles)
> 3.2 Read Byte for status (If status is OK, continue
otherwise repeat),
> assume 1 repeat is normal. (will need to wait approx
60us)
> 3.3 Repeat to 3.1 for the 128K Bytes.
>
> We have 128K Reads + 4*128K Writes + 2*128K Reads, so
just in read/write
> performance, excluding sector erase time, reading the
page increases the
> time to program by around 16%.

All right.  So, to figure the worst-case cost of that
requirement,
we're looking at programming a single byte in a sector
which is
otherwise full of non-0xFF data, over a JTAG interface. 
We're
comparing these two operations:

- read (almost) the sector over the JTAG interface, erase
the sector,
  and then write it all back

versus:

- erase the sector, and then write one byte.

The erasure time is needed no matter what we do; that
doesn't count.

On the board I happen to have handy, it takes 26 seconds to
write a
full 128k flash sector over the JTAG interface.  Unless this
is
extremely slow compared to what's typical out there, I'd
tend to agree
that preserving unloaded sector contents is important to
leave
optional, or not require at all.  I wouldn't mind waiting a
handful of
seconds, but even ten would be too long.

Jim Blandy wrote:

>
>On the board I happen to have handy, it takes 26 seconds
to write a
>full 128k flash sector over the JTAG interface.  Unless
this is
>extremely slow compared to what's typical out there,
I'd tend to agree
>that preserving unloaded sector contents is important to
leave
>optional, or not require at all.  I wouldn't mind
waiting a handful of
>seconds, but even ten would be too long.
>  
>
Yes, also, you don't want (or need) to do it if the whole
sector is
going to be programmed.  Maybe another memory attribute
would be
"Preserve unaltered contents of flash on
reprogram"

To put it in perspective (I don't know what type of flash
you have, if
you give me a part number, I'd be interested to do this
analysis on your
part),

Using an accelerated buffer programming algorithm for the
Spansion S29GL
family of flash the following is the theoretical typical
case sector
programming time:

Typical time to program 32 bytes = 240us
Therefore 128K Bytes / 32 * 240us = 983ms total typical
sector
programming time

It might be an unfair comparison, so using the traditional
"Byte at a
time" algorithm for the same family, we get:

Typical time to program 1 byte = 60us
Therefore 128K Bytes * 60us = 7.8 seconds total typical
sector
programming time

Both of which are significantly under your JTag Speeds to do
the same
operation.

However that said, your Jtag speeds are very respectable,
I've seen lots
worse, 10-20 (or more) times slower programming of flash
over Jtag.

Steven J