Yahoo Groups archive

Lpc2000

Index last updated: 2026-04-28 23:31 UTC

Message

Re: [lpc2000] Slow OCD Remote/Insight debugging

2005-09-30 by sig5534@hotmail.com

When I said 5 or 6 seconds, I was not trying to be that precise.  These were not measurements taken with any stop watch or by any elaborate timing method.  That was just my feeling.  It could be anywhere from 3-7 seconds as far as I now.  I don't pay that close attention to it.  I'm always erasing different amounts of memory.  Sometimes it is all 256K, and other times it is just 32K.  It depends.  So I get different times.

But programming is not what my point was about, as far as being JTAG speed.  Reading back the data for large blocks during debugging is where the speed comes in.  Stopping and starting breakpoints is when the data has to be pulled back through the JTAG.  That is a lot faster at 1M than at 14K.  All of my half dozen windows fill quick.

Chris.

 
  ----- Original Message ----- 
  From: Paul Curtis 
  To: lpc2000@yahoogroups.com 
  Sent: Wednesday, September 28, 2005 8:21 AM
  Subject: RE: [lpc2000] Slow OCD Remote/Insight debugging


  Chris, 

  > I guess you missed the point.

  Well, let's work through it shall we.

  > The programming time is 
  > limited by the internal operation of the LPC CPU.

  Sure.  I understand that.

  > Erasing sectors is time controlled by the CPU.  The jtag link has 
  > nothing to do with this.  Those time delays are the same for 
  > any programmer.  Just try doing some IAP yourself from your 
  > own internal code and you will understand real quick.  You 
  > can't do it any faster even from inside the CPU.

  I'm sorry if I'm a little thick here.  You'll need to help me with the
  mathematics.

  Here's a little dump of what CrossWorks does when downloading using a
  CrossConnect:

  Downloading Loader to USB CrossConnect for ARM
  Programming 3.6 KB at 0x40000000
  Programming completed in 141 ms -- 26,808 bytes/sec
  Downloading keil_mcb2140.elf to USB CrossConnect for ARM
  Erasing completed in 2.1 s -- 23,499 bytes/sec
  Programming 47.4 KB at 0x0
  Programming completed in 1.5 s -- 32,575 bytes/sec
  Verifying keil_mcb2140.elf on USB CrossConnect for ARM
  Verifying completed in 375 ms -- 130,216 bytes/sec

  I downloaded 3.6K to RAM in 141ms, then I erased the LPC2k's flash in
  2.1s, then I downloaded 47.5K to flash in 1.5s, and then I verified that
  it had downloaded correctly in 375ms.

  Total time from cold to debugging = 4.1s.

  With a wiggler:

  Downloading Loader to Macraigor Wiggler (20 Pin)
  Programming 3.6 KB  at 0x40000000
  Programming completed in 312 ms --12,320 bytes/sec
  Downloading keil_mcb2140.elf to Macraigor Wiggler (20 Pin)
  Erasing completed in 2.0 s -- 24,078 bytes/sec
  Programming 47.4 KB at 0x0
  Programming completed in 2.9 s -- 16,859 bytes/sec
  Verifying keil_mcb2140.elf on Macraigor Wiggler (20 Pin)
  Verifying completed in 390 ms --126,317 bytes/sec

  So, I downloaded 3.6K to RAM in 312ms, then I erased the LPC2k's flash
  in 2.0s, then I downloaded 47.5K to flash in 2.9s, and then I verified
  that it had downloaded correctly in 390ms.

  Total time from cold to debugging = 5.6s.

  You said:

  "The download to the Flash/RAM only takes a couple seconds or less. But
  the programming of the flash takes about 6 seconds.  That is due to the
  internal speed..."

  Yes, so eight seconds for 48K to download and program.  That compares to
  5.6s to download and program on the wiggler and 4.1s on the
  CrossConnect.

  So, where am I making my mistake, and why is the JTAGjet so much better?

  -- Paul.





  SPONSORED LINKS Microprocessor  Microcontrollers  Pic microcontrollers  
        8051 microprocessor  


------------------------------------------------------------------------------
  YAHOO! GROUPS LINKS 

    a..  Visit your group "lpc2000" on the web.
      
    b..  To unsubscribe from this group, send an email to:
     lpc2000-unsubscribe@yahoogroups.com
      
    c..  Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service. 


------------------------------------------------------------------------------



[Non-text portions of this message have been removed]

Attachments

Move to quarantaine

This moves the raw source file on disk only. The archive index is not changed automatically, so you still need to run a manual refresh afterward.