Blogteam:
In the last 4 weeks iSYSTEM had a survey on their web page with following question: How much time would you expect a standard debugger to download, erase, flash and verify a 150kByte application?
Werner, how would you answer that question?
Werner:
The answer depends on
- the flash itself
- the type of on-chip debug interface,
- the potential of loading of a flash monitor software,
- the sector size
- the size of code to be downloaded,
- the debugger software and
- the debugger hardware.
Blogteam:
Can you explain the different aspects?
Werner:
The flash itself is a major speed factor. Flash architectures differ in the algorithm they require for flash programming, and these algorithms specify different numbers of cycles and pulses they need for erasing and programming.
Blogteam:
How does the on-chip debug interface and the monitor software influence flash programming times?
Werner:
On-chip debug interfaces vary a lot in interface speed. JTAG is a very common interface, but in some cases it is not the fastet one to use.
A really huge speed boost is gained by using flash monitor software. A monitor software is a little program copied from the debugger to the target CPU. Instead of the debugger controlling which memory areas are to be programmed in the flash, the monitor receives all data and takes over the control. The performance gain is in average 3 times, but with some architectures the factor goes up by 27!
Blogteam:
Wow, that´s a boost! And how much influence has the code and sector size on the download times?
Werner:
If we talk about programming the complete flash the download time increases linear to the size of code. Sector sizes are irrelevant on a complete flash programming.
But as soon as we consider partial flash programming e.g. to implement a break point, then sector sizes play an important time factor. As smaller the sector size as faster the programming will be done.
Blogteam:
And the last aspects, the debugger software and hardware?
Werner:
To program a flash a specific protocol and a tight timing with distinct voltage levels is needed on the lines of the flash. A PC is not capable to control this interface directly. A sophisticated level converter between PC and MCU is necessary, a so called hardware debugger. And this hardware debugger is controlled by a debugger software.
A major time factor of a debugger software and hardware is how fast they can communicate, e.g. does the software connect to the hardware debugger via USB 1.0 or USB 2.0 or Ethernet? Another point to consider is whether the hardware debugger has internal memory to buffer download data.
Blogteam:
So, the customer has to take care of a lot of things! What´s the answer of iSYSTEM to that?
Werner:
iSYSTEM provides flash monitor software for many CPUs. If there is no monitor software, iSYSTEM has on open interface (UMI=Universal Monitor Interface) that allows the customer to write a flash specific monitor software that integrates seamlessly into our integrated development environment WinIDEA (which is the debugger software).
iSYSTEM customers compliment our tools (WinIDEA and Blue Boxes) for their high speed in flash programming!
Blogteam:
Thanks Werner!
Who is Werner?
Posted by: Erol Simsek | Jun 29, 2009 at 09:36 PM
This is Werner!
http://www.flickr.com/photos/isystem/3326788144/
Posted by: Christiane Vogt | Jul 01, 2009 at 08:58 AM