This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: GDB support for Flash memory programming


Steven Johnson <sjohnson@sakuraindustries.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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]