Yahoo Groups archive

Lpc2000

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

Thread

Slow OCD Remote/Insight debugging

Slow OCD Remote/Insight debugging

2005-09-26 by Blagoj Kupev

Hi there,

I'm beginner in ARM7 world and everything looks strange to me. I've 
build wiggler compatible interface and i have MCB2130 from Keil. I have 
few questions regarding debuging:
1. Why OCD Remote/Insight combination works 10 times slower compared to 
debug speed when i try to debug same SW using Rowley's Cross Studio? (i can not 
connect OCD Remote with speed parameter lower than 3).
2. I found some discussion but still it is not clear to me if i can 
debug sw in flash with OCD Remote? I read that OCD Remote does not 
support hardware breakpoints that is requred for debugging in flash. Is 
this true or i'm missing something?
Best regards,
Blagoj

Re: [lpc2000] Slow OCD Remote/Insight debugging

2005-09-26 by sig5534@hotmail.com

I saw the same problem with the wiggler.  Had problems connecting to my LPC2104 at anything but really low speeds.  The OCD is not a professional level debugger.  In order to debug a program that you intend to run in FLASH, you have to download your program into FLASH.  OCD can't do this.

I bought a Signum JTAGJet and it is worth it. It downloads and programs to flash, as well as having a superb C/ASM debugger.   I use the GNUARM for compiling, but I much prefer a professional debugger.

Chris.
Show quoted textHide quoted text
  ----- Original Message ----- 
  From: Blagoj Kupev 
  To: lpc2000@yahoogroups.com 
  Sent: Monday, September 26, 2005 12:09 AM
  Subject: [lpc2000] Slow OCD Remote/Insight debugging


  Hi there,

  I'm beginner in ARM7 world and everything looks strange to me. I've 
  build wiggler compatible interface and i have MCB2130 from Keil. I have 
  few questions regarding debuging:
  1. Why OCD Remote/Insight combination works 10 times slower compared to 
  debug speed when i try to debug same SW using Rowley's Cross Studio? (i can not 
  connect OCD Remote with speed parameter lower than 3).
  2. I found some discussion but still it is not clear to me if i can 
  debug sw in flash with OCD Remote? I read that OCD Remote does not 
  support hardware breakpoints that is requred for debugging in flash. Is 
  this true or i'm missing something?
  Best regards,
  Blagoj




  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]

Re: [lpc2000] Slow OCD Remote/Insight debugging

2005-09-26 by Michael Johnson

Wigglers work - you just have to choose (perhaps even buy) the 
appropriate software to drive them.

Michael
Show quoted textHide quoted text
>I saw the same problem with the wiggler.  Had problems connecting to my LPC2104 at anything but really low speeds.  The OCD is not a professional level debugger.  In order to debug a program that you intend to run in FLASH, you have to download your program into FLASH.  OCD can't do this.
>
>I bought a Signum JTAGJet and it is worth it. It downloads and programs to flash, as well as having a superb C/ASM debugger.   I use the GNUARM for compiling, but I much prefer a professional debugger.
>
>Chris.
>
> 
>  ----- Original Message ----- 
>  From: Blagoj Kupev 
>  To: lpc2000@yahoogroups.com 
>  Sent: Monday, September 26, 2005 12:09 AM
>  Subject: [lpc2000] Slow OCD Remote/Insight debugging
>
>
>  Hi there,
>
>  I'm beginner in ARM7 world and everything looks strange to me. I've 
>  build wiggler compatible interface and i have MCB2130 from Keil. I have 
>  few questions regarding debuging:
>  1. Why OCD Remote/Insight combination works 10 times slower compared to 
>  debug speed when i try to debug same SW using Rowley's Cross Studio? (i can not 
>  connect OCD Remote with speed parameter lower than 3).
>  2. I found some discussion but still it is not clear to me if i can 
>  debug sw in flash with OCD Remote? I read that OCD Remote does not 
>  support hardware breakpoints that is requred for debugging in flash. Is 
>  this true or i'm missing something?
>  Best regards,
>  Blagoj
>
>
>
>
>  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]
>
>
>
>
> 
>Yahoo! Groups Links
>
>
>
> 
>
>
>
>  
>

Re: [lpc2000] Slow OCD Remote/Insight debugging

2005-09-26 by sig5534@hotmail.com

And what would that be?  I thought that a download of the OCD app from the same people who make the hardware should likely work.  I can understand some really limited features, but a 4kHz connection speed? That really surprised me.

Chris.
Show quoted textHide quoted text
  ----- Original Message ----- 
  From: Michael Johnson 
  To: lpc2000@yahoogroups.com 
  Sent: Monday, September 26, 2005 4:37 AM
  Subject: Re: [lpc2000] Slow OCD Remote/Insight debugging


  Wigglers work - you just have to choose (perhaps even buy) the 
  appropriate software to drive them.

  Michael

  >I saw the same problem with the wiggler.  Had problems connecting to my LPC2104 at anything but really low speeds.  The OCD is not a professional level debugger.  In order to debug a program that you intend to run in FLASH, you have to download your program into FLASH.  OCD can't do this.
  >
  >I bought a Signum JTAGJet and it is worth it. It downloads and programs to flash, as well as having a superb C/ASM debugger.   I use the GNUARM for compiling, but I much prefer a professional debugger.
  >
  >Chris.
  >
  > 
  >  ----- Original Message ----- 
  >  From: Blagoj Kupev 
  >  To: lpc2000@yahoogroups.com 
  >  Sent: Monday, September 26, 2005 12:09 AM
  >  Subject: [lpc2000] Slow OCD Remote/Insight debugging
  >
  >
  >  Hi there,
  >
  >  I'm beginner in ARM7 world and everything looks strange to me. I've 
  >  build wiggler compatible interface and i have MCB2130 from Keil. I have 
  >  few questions regarding debuging:
  >  1. Why OCD Remote/Insight combination works 10 times slower compared to 
  >  debug speed when i try to debug same SW using Rowley's Cross Studio? (i can not 
  >  connect OCD Remote with speed parameter lower than 3).
  >  2. I found some discussion but still it is not clear to me if i can 
  >  debug sw in flash with OCD Remote? I read that OCD Remote does not 
  >  support hardware breakpoints that is requred for debugging in flash. Is 
  >  this true or i'm missing something?
  >  Best regards,
  >  Blagoj
  >
  >
  >
  >
  >  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]
  >
  >
  >
  >
  > 
  >Yahoo! Groups Links
  >
  >
  >
  > 
  >
  >
  >
  >  
  >



------------------------------------------------------------------------------
  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]

Re: [lpc2000] Slow OCD Remote/Insight debugging

2005-09-26 by Michael Johnson

We've found that you can't drive the signals on a PC parallel port at 
more than 4kHz (this is in GPIO/bit bang mode - EPP/ECP is a different 
tale). Even with this limitation CrossWorks for ARM has a flash download 
speed of 14Kbytes per second to the LPC21xx.

Michael
Show quoted textHide quoted text
>And what would that be?  I thought that a download of the OCD app from the same people who make the hardware should likely work.  I can understand some really limited features, but a 4kHz connection speed? That really surprised me.
>
>Chris.
>
>  ----- Original Message ----- 
>  From: Michael Johnson 
>  To: lpc2000@yahoogroups.com 
>  Sent: Monday, September 26, 2005 4:37 AM
>  Subject: Re: [lpc2000] Slow OCD Remote/Insight debugging
>
>
>  Wigglers work - you just have to choose (perhaps even buy) the 
>  appropriate software to drive them.
>
>  Michael
>
>  >I saw the same problem with the wiggler.  Had problems connecting to my LPC2104 at anything but really low speeds.  The OCD is not a professional level debugger.  In order to debug a program that you intend to run in FLASH, you have to download your program into FLASH.  OCD can't do this.
>  >
>  >I bought a Signum JTAGJet and it is worth it. It downloads and programs to flash, as well as having a superb C/ASM debugger.   I use the GNUARM for compiling, but I much prefer a professional debugger.
>  >
>  >Chris.
>  >
>  > 
>  >  ----- Original Message ----- 
>  >  From: Blagoj Kupev 
>  >  To: lpc2000@yahoogroups.com 
>  >  Sent: Monday, September 26, 2005 12:09 AM
>  >  Subject: [lpc2000] Slow OCD Remote/Insight debugging
>  >
>  >
>  >  Hi there,
>  >
>  >  I'm beginner in ARM7 world and everything looks strange to me. I've 
>  >  build wiggler compatible interface and i have MCB2130 from Keil. I have 
>  >  few questions regarding debuging:
>  >  1. Why OCD Remote/Insight combination works 10 times slower compared to 
>  >  debug speed when i try to debug same SW using Rowley's Cross Studio? (i can not 
>  >  connect OCD Remote with speed parameter lower than 3).
>  >  2. I found some discussion but still it is not clear to me if i can 
>  >  debug sw in flash with OCD Remote? I read that OCD Remote does not 
>  >  support hardware breakpoints that is requred for debugging in flash. Is 
>  >  this true or i'm missing something?
>  >  Best regards,
>  >  Blagoj
>  >
>  >
>  >
>  >
>  >  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]
>  >
>  >
>  >
>  >
>  > 
>  >Yahoo! Groups Links
>  >
>  >
>  >
>  > 
>  >
>  >
>  >
>  >  
>  >
>
>
>
>------------------------------------------------------------------------------
>  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]
>
>
>
>
> 
>Yahoo! Groups Links
>
>
>
> 
>
>
>  
>

Re: [lpc2000] Slow OCD Remote/Insight debugging

2005-09-26 by Michael Johnson

Whoops I meant 400Khz.....
Show quoted textHide quoted text
>We've found that you can't drive the signals on a PC parallel port at 
>more than 4kHz (this is in GPIO/bit bang mode - EPP/ECP is a different 
>tale). Even with this limitation CrossWorks for ARM has a flash download 
>speed of 14Kbytes per second to the LPC21xx.
>
>Michael
>
>  
>
>>And what would that be?  I thought that a download of the OCD app from the same people who make the hardware should likely work.  I can understand some really limited features, but a 4kHz connection speed? That really surprised me.
>>
>>Chris.
>>
>> ----- Original Message ----- 
>> From: Michael Johnson 
>> To: lpc2000@yahoogroups.com 
>> Sent: Monday, September 26, 2005 4:37 AM
>> Subject: Re: [lpc2000] Slow OCD Remote/Insight debugging
>>
>>
>> Wigglers work - you just have to choose (perhaps even buy) the 
>> appropriate software to drive them.
>>
>> Michael
>>
>> >I saw the same problem with the wiggler.  Had problems connecting to my LPC2104 at anything but really low speeds.  The OCD is not a professional level debugger.  In order to debug a program that you intend to run in FLASH, you have to download your program into FLASH.  OCD can't do this.
>> >
>> >I bought a Signum JTAGJet and it is worth it. It downloads and programs to flash, as well as having a superb C/ASM debugger.   I use the GNUARM for compiling, but I much prefer a professional debugger.
>> >
>> >Chris.
>> >
>> > 
>> >  ----- Original Message ----- 
>> >  From: Blagoj Kupev 
>> >  To: lpc2000@yahoogroups.com 
>> >  Sent: Monday, September 26, 2005 12:09 AM
>> >  Subject: [lpc2000] Slow OCD Remote/Insight debugging
>> >
>> >
>> >  Hi there,
>> >
>> >  I'm beginner in ARM7 world and everything looks strange to me. I've 
>> >  build wiggler compatible interface and i have MCB2130 from Keil. I have 
>> >  few questions regarding debuging:
>> >  1. Why OCD Remote/Insight combination works 10 times slower compared to 
>> >  debug speed when i try to debug same SW using Rowley's Cross Studio? (i can not 
>> >  connect OCD Remote with speed parameter lower than 3).
>> >  2. I found some discussion but still it is not clear to me if i can 
>> >  debug sw in flash with OCD Remote? I read that OCD Remote does not 
>> >  support hardware breakpoints that is requred for debugging in flash. Is 
>> >  this true or i'm missing something?
>> >  Best regards,
>> >  Blagoj
>> >
>> >
>> >
>> >
>> >  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]
>> >
>> >
>> >
>> >
>> > 
>> >Yahoo! Groups Links
>> >
>> >
>> >
>> > 
>> >
>> >
>> >
>> >  
>> >
>>
>>
>>
>>------------------------------------------------------------------------------
>> 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]
>>
>>
>>
>>
>>
>>Yahoo! Groups Links
>>
>>
>>
>>
>>
>>
>> 
>>
>>    
>>
>
>
>
>
> 
>Yahoo! Groups Links
>
>
>
> 
>
>
>
>  
>

Re: [lpc2000] Slow OCD Remote/Insight debugging

2005-09-27 by sig5534@hotmail.com

14K Wow.  And I thought the 1M rate I'm getting with the Signum JetJTAG was slow.  I can't imagine doing tons of debuging at 14K.

Chris.
Show quoted textHide quoted text
  ----- Original Message ----- 
  From: Michael Johnson 
  To: lpc2000@yahoogroups.com 
  Sent: Monday, September 26, 2005 5:58 AM
  Subject: Re: [lpc2000] Slow OCD Remote/Insight debugging


  We've found that you can't drive the signals on a PC parallel port at 
  more than 4kHz (this is in GPIO/bit bang mode - EPP/ECP is a different 
  tale). Even with this limitation CrossWorks for ARM has a flash download 
  speed of 14Kbytes per second to the LPC21xx.

  Michael

  >And what would that be?  I thought that a download of the OCD app from the same people who make the hardware should likely work.  I can understand some really limited features, but a 4kHz connection speed? That really surprised me.
  >
  >Chris.
  >
  >  ----- Original Message ----- 
  >  From: Michael Johnson 
  >  To: lpc2000@yahoogroups.com 
  >  Sent: Monday, September 26, 2005 4:37 AM
  >  Subject: Re: [lpc2000] Slow OCD Remote/Insight debugging
  >
  >
  >  Wigglers work - you just have to choose (perhaps even buy) the 
  >  appropriate software to drive them.
  >
  >  Michael
  >
  >  >I saw the same problem with the wiggler.  Had problems connecting to my LPC2104 at anything but really low speeds.  The OCD is not a professional level debugger.  In order to debug a program that you intend to run in FLASH, you have to download your program into FLASH.  OCD can't do this.
  >  >
  >  >I bought a Signum JTAGJet and it is worth it. It downloads and programs to flash, as well as having a superb C/ASM debugger.   I use the GNUARM for compiling, but I much prefer a professional debugger.
  >  >
  >  >Chris.
  >  >
  >  > 
  >  >  ----- Original Message ----- 
  >  >  From: Blagoj Kupev 
  >  >  To: lpc2000@yahoogroups.com 
  >  >  Sent: Monday, September 26, 2005 12:09 AM
  >  >  Subject: [lpc2000] Slow OCD Remote/Insight debugging
  >  >
  >  >
  >  >  Hi there,
  >  >
  >  >  I'm beginner in ARM7 world and everything looks strange to me. I've 
  >  >  build wiggler compatible interface and i have MCB2130 from Keil. I have 
  >  >  few questions regarding debuging:
  >  >  1. Why OCD Remote/Insight combination works 10 times slower compared to 
  >  >  debug speed when i try to debug same SW using Rowley's Cross Studio? (i can not 
  >  >  connect OCD Remote with speed parameter lower than 3).
  >  >  2. I found some discussion but still it is not clear to me if i can 
  >  >  debug sw in flash with OCD Remote? I read that OCD Remote does not 
  >  >  support hardware breakpoints that is requred for debugging in flash. Is 
  >  >  this true or i'm missing something?
  >  >  Best regards,
  >  >  Blagoj
  >  >
  >  >
  >  >
  >  >
  >  >  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]
  >  >
  >  >
  >  >
  >  >
  >  > 
  >  >Yahoo! Groups Links
  >  >
  >  >
  >  >
  >  > 
  >  >
  >  >
  >  >
  >  >  
  >  >
  >
  >
  >
  >------------------------------------------------------------------------------
  >  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]
  >
  >
  >
  >
  > 
  >Yahoo! Groups Links
  >
  >
  >
  > 
  >
  >
  >  
  >



  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]

Re: [lpc2000] Slow OCD Remote/Insight debugging

2005-09-27 by Michael Johnson

Does 1M==1Mbyte or 128Kbyte? Which LPC21xx device are you using? Are you 
downloading into flash? How long does it take for you to download 64K 
bytes into the flash of an LPC21xx?

Michael
Show quoted textHide quoted text
>14K Wow.  And I thought the 1M rate I'm getting with the Signum JetJTAG was slow.  I can't imagine doing tons of debuging at 14K.
>
>Chris.
>
>
>  ----- Original Message ----- 
>  From: Michael Johnson 
>  To: lpc2000@yahoogroups.com 
>  Sent: Monday, September 26, 2005 5:58 AM
>  Subject: Re: [lpc2000] Slow OCD Remote/Insight debugging
>
>
>  We've found that you can't drive the signals on a PC parallel port at 
>  more than 4kHz (this is in GPIO/bit bang mode - EPP/ECP is a different 
>  tale). Even with this limitation CrossWorks for ARM has a flash download 
>  speed of 14Kbytes per second to the LPC21xx.
>
>  Michael
>
>  >And what would that be?  I thought that a download of the OCD app from the same people who make the hardware should likely work.  I can understand some really limited features, but a 4kHz connection speed? That really surprised me.
>  >
>  >Chris.
>  >
>  >  ----- Original Message ----- 
>  >  From: Michael Johnson 
>  >  To: lpc2000@yahoogroups.com 
>  >  Sent: Monday, September 26, 2005 4:37 AM
>  >  Subject: Re: [lpc2000] Slow OCD Remote/Insight debugging
>  >
>  >
>  >  Wigglers work - you just have to choose (perhaps even buy) the 
>  >  appropriate software to drive them.
>  >
>  >  Michael
>  >
>  >  >I saw the same problem with the wiggler.  Had problems connecting to my LPC2104 at anything but really low speeds.  The OCD is not a professional level debugger.  In order to debug a program that you intend to run in FLASH, you have to download your program into FLASH.  OCD can't do this.
>  >  >
>  >  >I bought a Signum JTAGJet and it is worth it. It downloads and programs to flash, as well as having a superb C/ASM debugger.   I use the GNUARM for compiling, but I much prefer a professional debugger.
>  >  >
>  >  >Chris.
>  >  >
>  >  > 
>  >  >  ----- Original Message ----- 
>  >  >  From: Blagoj Kupev 
>  >  >  To: lpc2000@yahoogroups.com 
>  >  >  Sent: Monday, September 26, 2005 12:09 AM
>  >  >  Subject: [lpc2000] Slow OCD Remote/Insight debugging
>  >  >
>  >  >
>  >  >  Hi there,
>  >  >
>  >  >  I'm beginner in ARM7 world and everything looks strange to me. I've 
>  >  >  build wiggler compatible interface and i have MCB2130 from Keil. I have 
>  >  >  few questions regarding debuging:
>  >  >  1. Why OCD Remote/Insight combination works 10 times slower compared to 
>  >  >  debug speed when i try to debug same SW using Rowley's Cross Studio? (i can not 
>  >  >  connect OCD Remote with speed parameter lower than 3).
>  >  >  2. I found some discussion but still it is not clear to me if i can 
>  >  >  debug sw in flash with OCD Remote? I read that OCD Remote does not 
>  >  >  support hardware breakpoints that is requred for debugging in flash. Is 
>  >  >  this true or i'm missing something?
>  >  >  Best regards,
>  >  >  Blagoj
>  >  >
>  >  >
>  >  >
>  >  >
>  >  >  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]
>  >  >
>  >  >
>  >  >
>  >  >
>  >  > 
>  >  >Yahoo! Groups Links
>  >  >
>  >  >
>  >  >
>  >  > 
>  >  >
>  >  >
>  >  >
>  >  >  
>  >  >
>  >
>  >
>  >
>  >------------------------------------------------------------------------------
>  >  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]
>  >
>  >
>  >
>  >
>  > 
>  >Yahoo! Groups Links
>  >
>  >
>  >
>  > 
>  >
>  >
>  >  
>  >
>
>
>
>  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]
>
>
>
>
> 
>Yahoo! Groups Links
>
>
>
> 
>
>
>  
>

RE: [lpc2000] Slow OCD Remote/Insight debugging

2005-09-27 by Paul Curtis

Chris, 

> >  We've found that you can't drive the signals on a PC parallel port
at  
> > more than 4kHz (this is in GPIO/bit bang mode - EPP/ECP is a
different  
> > tale). Even with this limitation CrossWorks for ARM has a flash 
> > download  speed of 14Kbytes per second to the LPC21xx.

> >14K Wow.  And I thought the 1M rate I'm getting with the 
> Signum JetJTAG was slow.  I can't imagine doing tons of 
> debuging at 14K.
> 
> Chris.

So, how fast does your Signum device load into an LPC2000's flash?  Bet
it's not much faster than 14K/second and will never approach a "1M"
rate.  What's an "1M" rate?  Is that a TCK frequency or the programming
speed in bits per second or bytes per second?

The CrossConnect loads at over 180Kbytes/second onto an Evaluator-7T
into RAM, so that equates to a download speed of 1.4Mbit/second.  On
Xscale it's over 200K/second equating to 1.6Mbit/second.  Not too shabby
for a £99 device.  However, the Wiggler or one of its many clones isn't
at all bad for low-end development on small devices--about 1/5th the
speed for 1/5th the price (if you purchase a clone).

-- Paul.

Re: [lpc2000] Slow OCD Remote/Insight debugging

2005-09-28 by sig5534@hotmail.com

I mean 1 MegaByte per second.  That is my JTAG link speed.  I have 2 designs right now I am working with, a LPC2106 and an LPC2124.  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 limitations of the flash erase and programming.  My code is too big to run in RAM.  All my code must be run from flash.

But the biggest difference is the Chameleon debugger of Signum.  That OCD is a joke, its not even a debugger, and the GNU Insight debugger ain't much better.  With Chameleon I can watch so many more things going on inside the CPU and it even breaks apart record structures and gives me the value on anything anytime I want, anywhere in my code.  Full display of both C and ASM real time, with both hardware and software breakpoints.  It is a top quality debugger.  One of the best I have ever used.  Feature rich.  Lots of powerful debugging features, in addition to full flash programming.

Moreover, I can control which areas of flash get reprogrammed.  That has turned out to be very useful.  Sometimes I do not want data areas to be changed when I reload the code.  So I skip those address ranges.  Very handy.

Chris.
Show quoted textHide quoted text
  ----- Original Message ----- 
  From: Michael Johnson 
  To: lpc2000@yahoogroups.com 
  Sent: Monday, September 26, 2005 10:42 PM
  Subject: Re: [lpc2000] Slow OCD Remote/Insight debugging


  Does 1M==1Mbyte or 128Kbyte? Which LPC21xx device are you using? Are you 
  downloading into flash? How long does it take for you to download 64K 
  bytes into the flash of an LPC21xx?

  Michael

  >14K Wow.  And I thought the 1M rate I'm getting with the Signum JetJTAG was slow.  I can't imagine doing tons of debuging at 14K.
  >
  >Chris.
  >
  >
  >  ----- Original Message ----- 
  >  From: Michael Johnson 
  >  To: lpc2000@yahoogroups.com 
  >  Sent: Monday, September 26, 2005 5:58 AM
  >  Subject: Re: [lpc2000] Slow OCD Remote/Insight debugging
  >
  >
  >  We've found that you can't drive the signals on a PC parallel port at 
  >  more than 4kHz (this is in GPIO/bit bang mode - EPP/ECP is a different 
  >  tale). Even with this limitation CrossWorks for ARM has a flash download 
  >  speed of 14Kbytes per second to the LPC21xx.
  >
  >  Michael
  >
  >  >And what would that be?  I thought that a download of the OCD app from the same people who make the hardware should likely work.  I can understand some really limited features, but a 4kHz connection speed? That really surprised me.
  >  >
  >  >Chris.
  >  >
  >  >  ----- Original Message ----- 
  >  >  From: Michael Johnson 
  >  >  To: lpc2000@yahoogroups.com 
  >  >  Sent: Monday, September 26, 2005 4:37 AM
  >  >  Subject: Re: [lpc2000] Slow OCD Remote/Insight debugging
  >  >
  >  >
  >  >  Wigglers work - you just have to choose (perhaps even buy) the 
  >  >  appropriate software to drive them.
  >  >
  >  >  Michael
  >  >
  >  >  >I saw the same problem with the wiggler.  Had problems connecting to my LPC2104 at anything but really low speeds.  The OCD is not a professional level debugger.  In order to debug a program that you intend to run in FLASH, you have to download your program into FLASH.  OCD can't do this.
  >  >  >
  >  >  >I bought a Signum JTAGJet and it is worth it. It downloads and programs to flash, as well as having a superb C/ASM debugger.   I use the GNUARM for compiling, but I much prefer a professional debugger.
  >  >  >
  >  >  >Chris.
  >  >  >
  >  >  > 
  >  >  >  ----- Original Message ----- 
  >  >  >  From: Blagoj Kupev 
  >  >  >  To: lpc2000@yahoogroups.com 
  >  >  >  Sent: Monday, September 26, 2005 12:09 AM
  >  >  >  Subject: [lpc2000] Slow OCD Remote/Insight debugging
  >  >  >
  >  >  >
  >  >  >  Hi there,
  >  >  >
  >  >  >  I'm beginner in ARM7 world and everything looks strange to me. I've 
  >  >  >  build wiggler compatible interface and i have MCB2130 from Keil. I have 
  >  >  >  few questions regarding debuging:
  >  >  >  1. Why OCD Remote/Insight combination works 10 times slower compared to 
  >  >  >  debug speed when i try to debug same SW using Rowley's Cross Studio? (i can not 
  >  >  >  connect OCD Remote with speed parameter lower than 3).
  >  >  >  2. I found some discussion but still it is not clear to me if i can 
  >  >  >  debug sw in flash with OCD Remote? I read that OCD Remote does not 
  >  >  >  support hardware breakpoints that is requred for debugging in flash. Is 
  >  >  >  this true or i'm missing something?
  >  >  >  Best regards,
  >  >  >  Blagoj
  >  >  >
  >  >  >
  >  >  >
  >  >  >
  >  >  >  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]
  >  >  >
  >  >  >
  >  >  >
  >  >  >
  >  >  > 
  >  >  >Yahoo! Groups Links
  >  >  >
  >  >  >
  >  >  >
  >  >  > 
  >  >  >
  >  >  >
  >  >  >
  >  >  >  
  >  >  >
  >  >
  >  >
  >  >
  >  >------------------------------------------------------------------------------
  >  >  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]
  >  >
  >  >
  >  >
  >  >
  >  > 
  >  >Yahoo! Groups Links
  >  >
  >  >
  >  >
  >  > 
  >  >
  >  >
  >  >  
  >  >
  >
  >
  >
  >  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]
  >
  >
  >
  >
  > 
  >Yahoo! Groups Links
  >
  >
  >
  > 
  >
  >
  >  
  >



  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]

Re: [lpc2000] Slow OCD Remote/Insight debugging

2005-09-28 by Michael Johnson

>I mean 1 MegaByte per second.  That is my JTAG link speed.  I have 2 designs right now I am working with, a LPC2106 and an LPC2124.  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 limitations of the flash erase and programming.  My code is too big to run in RAM.  All my code must be run from flash.
>  
>
What is the size of your program that takes 6 seconds to download to flash?

Michael
Show quoted textHide quoted text
>But the biggest difference is the Chameleon debugger of Signum.  That OCD is a joke, its not even a debugger, and the GNU Insight debugger ain't much better.  With Chameleon I can watch so many more things going on inside the CPU and it even breaks apart record structures and gives me the value on anything anytime I want, anywhere in my code.  Full display of both C and ASM real time, with both hardware and software breakpoints.  It is a top quality debugger.  One of the best I have ever used.  Feature rich.  Lots of powerful debugging features, in addition to full flash programming.
>
>Moreover, I can control which areas of flash get reprogrammed.  That has turned out to be very useful.  Sometimes I do not want data areas to be changed when I reload the code.  So I skip those address ranges.  Very handy.
>
>Chris.
>
> 
>
>
>  ----- Original Message ----- 
>  From: Michael Johnson 
>  To: lpc2000@yahoogroups.com 
>  Sent: Monday, September 26, 2005 10:42 PM
>  Subject: Re: [lpc2000] Slow OCD Remote/Insight debugging
>
>
>  Does 1M==1Mbyte or 128Kbyte? Which LPC21xx device are you using? Are you 
>  downloading into flash? How long does it take for you to download 64K 
>  bytes into the flash of an LPC21xx?
>
>  Michael
>
>  >14K Wow.  And I thought the 1M rate I'm getting with the Signum JetJTAG was slow.  I can't imagine doing tons of debuging at 14K.
>  >
>  >Chris.
>  >
>  >
>  >  ----- Original Message ----- 
>  >  From: Michael Johnson 
>  >  To: lpc2000@yahoogroups.com 
>  >  Sent: Monday, September 26, 2005 5:58 AM
>  >  Subject: Re: [lpc2000] Slow OCD Remote/Insight debugging
>  >
>  >
>  >  We've found that you can't drive the signals on a PC parallel port at 
>  >  more than 4kHz (this is in GPIO/bit bang mode - EPP/ECP is a different 
>  >  tale). Even with this limitation CrossWorks for ARM has a flash download 
>  >  speed of 14Kbytes per second to the LPC21xx.
>  >
>  >  Michael
>  >
>  >  >And what would that be?  I thought that a download of the OCD app from the same people who make the hardware should likely work.  I can understand some really limited features, but a 4kHz connection speed? That really surprised me.
>  >  >
>  >  >Chris.
>  >  >
>  >  >  ----- Original Message ----- 
>  >  >  From: Michael Johnson 
>  >  >  To: lpc2000@yahoogroups.com 
>  >  >  Sent: Monday, September 26, 2005 4:37 AM
>  >  >  Subject: Re: [lpc2000] Slow OCD Remote/Insight debugging
>  >  >
>  >  >
>  >  >  Wigglers work - you just have to choose (perhaps even buy) the 
>  >  >  appropriate software to drive them.
>  >  >
>  >  >  Michael
>  >  >
>  >  >  >I saw the same problem with the wiggler.  Had problems connecting to my LPC2104 at anything but really low speeds.  The OCD is not a professional level debugger.  In order to debug a program that you intend to run in FLASH, you have to download your program into FLASH.  OCD can't do this.
>  >  >  >
>  >  >  >I bought a Signum JTAGJet and it is worth it. It downloads and programs to flash, as well as having a superb C/ASM debugger.   I use the GNUARM for compiling, but I much prefer a professional debugger.
>  >  >  >
>  >  >  >Chris.
>  >  >  >
>  >  >  > 
>  >  >  >  ----- Original Message ----- 
>  >  >  >  From: Blagoj Kupev 
>  >  >  >  To: lpc2000@yahoogroups.com 
>  >  >  >  Sent: Monday, September 26, 2005 12:09 AM
>  >  >  >  Subject: [lpc2000] Slow OCD Remote/Insight debugging
>  >  >  >
>  >  >  >
>  >  >  >  Hi there,
>  >  >  >
>  >  >  >  I'm beginner in ARM7 world and everything looks strange to me. I've 
>  >  >  >  build wiggler compatible interface and i have MCB2130 from Keil. I have 
>  >  >  >  few questions regarding debuging:
>  >  >  >  1. Why OCD Remote/Insight combination works 10 times slower compared to 
>  >  >  >  debug speed when i try to debug same SW using Rowley's Cross Studio? (i can not 
>  >  >  >  connect OCD Remote with speed parameter lower than 3).
>  >  >  >  2. I found some discussion but still it is not clear to me if i can 
>  >  >  >  debug sw in flash with OCD Remote? I read that OCD Remote does not 
>  >  >  >  support hardware breakpoints that is requred for debugging in flash. Is 
>  >  >  >  this true or i'm missing something?
>  >  >  >  Best regards,
>  >  >  >  Blagoj
>  >  >  >
>  >  >  >
>  >  >  >
>  >  >  >
>  >  >  >  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]
>  >  >  >
>  >  >  >
>  >  >  >
>  >  >  >
>  >  >  > 
>  >  >  >Yahoo! Groups Links
>  >  >  >
>  >  >  >
>  >  >  >
>  >  >  > 
>  >  >  >
>  >  >  >
>  >  >  >
>  >  >  >  
>  >  >  >
>  >  >
>  >  >
>  >  >
>  >  >------------------------------------------------------------------------------
>  >  >  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]
>  >  >
>  >  >
>  >  >
>  >  >
>  >  > 
>  >  >Yahoo! Groups Links
>  >  >
>  >  >
>  >  >
>  >  > 
>  >  >
>  >  >
>  >  >  
>  >  >
>  >
>  >
>  >
>  >  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]
>  >
>  >
>  >
>  >
>  > 
>  >Yahoo! Groups Links
>  >
>  >
>  >
>  > 
>  >
>  >
>  >  
>  >
>
>
>
>  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]
>
>
>
>
> 
>Yahoo! Groups Links
>
>
>
> 
>
>
>  
>

Re: [lpc2000] Slow OCD Remote/Insight debugging

2005-09-28 by sig5534@hotmail.com

The time is all due to the erase I think.  As I recall it takes about 0.3 Sec per sector and there are about 16 sectors, so that is about 5 seconds right there.   Normally the defaut is to erase the entire part and that is what takes a few seconds.   My code on this one part right now is about 48K.  Moving the data doesn't take anytime at all.  It's waiting for the slow internal LPC flash processing.

Chris.
Show quoted textHide quoted text
  ----- Original Message ----- 
  From: Michael Johnson 
  To: lpc2000@yahoogroups.com 
  Sent: Tuesday, September 27, 2005 11:26 PM
  Subject: Re: [lpc2000] Slow OCD Remote/Insight debugging



  >I mean 1 MegaByte per second.  That is my JTAG link speed.  I have 2 designs right now I am working with, a LPC2106 and an LPC2124.  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 limitations of the flash erase and programming.  My code is too big to run in RAM.  All my code must be run from flash.
  >  
  >
  What is the size of your program that takes 6 seconds to download to flash?

  Michael

  >But the biggest difference is the Chameleon debugger of Signum.  That OCD is a joke, its not even a debugger, and the GNU Insight debugger ain't much better.  With Chameleon I can watch so many more things going on inside the CPU and it even breaks apart record structures and gives me the value on anything anytime I want, anywhere in my code.  Full display of both C and ASM real time, with both hardware and software breakpoints.  It is a top quality debugger.  One of the best I have ever used.  Feature rich.  Lots of powerful debugging features, in addition to full flash programming.
  >
  >Moreover, I can control which areas of flash get reprogrammed.  That has turned out to be very useful.  Sometimes I do not want data areas to be changed when I reload the code.  So I skip those address ranges.  Very handy.
  >
  >Chris.
  >
  > 
  >
  >
  >  ----- Original Message ----- 
  >  From: Michael Johnson 
  >  To: lpc2000@yahoogroups.com 
  >  Sent: Monday, September 26, 2005 10:42 PM
  >  Subject: Re: [lpc2000] Slow OCD Remote/Insight debugging
  >
  >
  >  Does 1M==1Mbyte or 128Kbyte? Which LPC21xx device are you using? Are you 
  >  downloading into flash? How long does it take for you to download 64K 
  >  bytes into the flash of an LPC21xx?
  >
  >  Michael
  >
  >  >14K Wow.  And I thought the 1M rate I'm getting with the Signum JetJTAG was slow.  I can't imagine doing tons of debuging at 14K.
  >  >
  >  >Chris.
  >  >
  >  >
  >  >  ----- Original Message ----- 
  >  >  From: Michael Johnson 
  >  >  To: lpc2000@yahoogroups.com 
  >  >  Sent: Monday, September 26, 2005 5:58 AM
  >  >  Subject: Re: [lpc2000] Slow OCD Remote/Insight debugging
  >  >
  >  >
  >  >  We've found that you can't drive the signals on a PC parallel port at 
  >  >  more than 4kHz (this is in GPIO/bit bang mode - EPP/ECP is a different 
  >  >  tale). Even with this limitation CrossWorks for ARM has a flash download 
  >  >  speed of 14Kbytes per second to the LPC21xx.
  >  >
  >  >  Michael
  >  >
  >  >  >And what would that be?  I thought that a download of the OCD app from the same people who make the hardware should likely work.  I can understand some really limited features, but a 4kHz connection speed? That really surprised me.
  >  >  >
  >  >  >Chris.
  >  >  >
  >  >  >  ----- Original Message ----- 
  >  >  >  From: Michael Johnson 
  >  >  >  To: lpc2000@yahoogroups.com 
  >  >  >  Sent: Monday, September 26, 2005 4:37 AM
  >  >  >  Subject: Re: [lpc2000] Slow OCD Remote/Insight debugging
  >  >  >
  >  >  >
  >  >  >  Wigglers work - you just have to choose (perhaps even buy) the 
  >  >  >  appropriate software to drive them.
  >  >  >
  >  >  >  Michael
  >  >  >
  >  >  >  >I saw the same problem with the wiggler.  Had problems connecting to my LPC2104 at anything but really low speeds.  The OCD is not a professional level debugger.  In order to debug a program that you intend to run in FLASH, you have to download your program into FLASH.  OCD can't do this.
  >  >  >  >
  >  >  >  >I bought a Signum JTAGJet and it is worth it. It downloads and programs to flash, as well as having a superb C/ASM debugger.   I use the GNUARM for compiling, but I much prefer a professional debugger.
  >  >  >  >
  >  >  >  >Chris.
  >  >  >  >
  >  >  >  > 
  >  >  >  >  ----- Original Message ----- 
  >  >  >  >  From: Blagoj Kupev 
  >  >  >  >  To: lpc2000@yahoogroups.com 
  >  >  >  >  Sent: Monday, September 26, 2005 12:09 AM
  >  >  >  >  Subject: [lpc2000] Slow OCD Remote/Insight debugging
  >  >  >  >
  >  >  >  >
  >  >  >  >  Hi there,
  >  >  >  >
  >  >  >  >  I'm beginner in ARM7 world and everything looks strange to me. I've 
  >  >  >  >  build wiggler compatible interface and i have MCB2130 from Keil. I have 
  >  >  >  >  few questions regarding debuging:
  >  >  >  >  1. Why OCD Remote/Insight combination works 10 times slower compared to 
  >  >  >  >  debug speed when i try to debug same SW using Rowley's Cross Studio? (i can not 
  >  >  >  >  connect OCD Remote with speed parameter lower than 3).
  >  >  >  >  2. I found some discussion but still it is not clear to me if i can 
  >  >  >  >  debug sw in flash with OCD Remote? I read that OCD Remote does not 
  >  >  >  >  support hardware breakpoints that is requred for debugging in flash. Is 
  >  >  >  >  this true or i'm missing something?
  >  >  >  >  Best regards,
  >  >  >  >  Blagoj
  >  >  >  >
  >  >  >  >
  >  >  >  >
  >  >  >  >
  >  >  >  >  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]
  >  >  >  >
  >  >  >  >
  >  >  >  >
  >  >  >  >
  >  >  >  > 
  >  >  >  >Yahoo! Groups Links
  >  >  >  >
  >  >  >  >
  >  >  >  >
  >  >  >  > 
  >  >  >  >
  >  >  >  >
  >  >  >  >
  >  >  >  >  
  >  >  >  >
  >  >  >
  >  >  >
  >  >  >
  >  >  >------------------------------------------------------------------------------
  >  >  >  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]
  >  >  >
  >  >  >
  >  >  >
  >  >  >
  >  >  > 
  >  >  >Yahoo! Groups Links
  >  >  >
  >  >  >
  >  >  >
  >  >  > 
  >  >  >
  >  >  >
  >  >  >  
  >  >  >
  >  >
  >  >
  >  >
  >  >  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]
  >  >
  >  >
  >  >
  >  >
  >  > 
  >  >Yahoo! Groups Links
  >  >
  >  >
  >  >
  >  > 
  >  >
  >  >
  >  >  
  >  >
  >
  >
  >
  >  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]
  >
  >
  >
  >
  > 
  >Yahoo! Groups Links
  >
  >
  >
  > 
  >
  >
  >  
  >



  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]

RE: [lpc2000] Slow OCD Remote/Insight debugging

2005-09-28 by Paul Curtis

Hi, 

> The time is all due to the erase I think.  As I recall it 
> takes about 0.3 Sec per sector and there are about 16 
> sectors, so that is about 5 seconds right there.   Normally 
> the defaut is to erase the entire part and that is what takes 
> a few seconds.   My code on this one part right now is about 
> 48K.  Moving the data doesn't take anytime at all.  It's 
> waiting for the slow internal LPC flash processing.

Ok, so 48K in 6 seconds is 8K per second to download and flash.  Gee.
That's way slower than CrossWorks' wiggler implementation which will
erase, download, and flash at 14KB per second on an LPC.  The
CrossConnect will download and flash at 34K per second on an LPC.  So,
if you have 48K, the CrossConnect will erase, download, and complete
flashing within 2s 2s of hitting the Go button.

Seems like the JTAGjet isn't quick so "jet" after all.

-- Paul.
Show quoted textHide quoted text
> 
> Chris.
> 
>   ----- Original Message -----
>   From: Michael Johnson
>   To: lpc2000@yahoogroups.com
>   Sent: Tuesday, September 27, 2005 11:26 PM
>   Subject: Re: [lpc2000] Slow OCD Remote/Insight debugging
> 
> 
> 
>   >I mean 1 MegaByte per second.  That is my JTAG link speed. 
>  I have 2 designs right now I am working with, a LPC2106 and 
> an LPC2124.  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 
> limitations of the flash erase and programming.  My code is 
> too big to run in RAM.  All my code must be run from flash.
>   >
>   >
>   What is the size of your program that takes 6 seconds to 
> download to flash?
> 
>   Michael
> 
>   >But the biggest difference is the Chameleon debugger of 
> Signum.  That OCD is a joke, its not even a debugger, and the 
> GNU Insight debugger ain't much better.  With Chameleon I can 
> watch so many more things going on inside the CPU and it even 
> breaks apart record structures and gives me the value on 
> anything anytime I want, anywhere in my code.  Full display 
> of both C and ASM real time, with both hardware and software 
> breakpoints.  It is a top quality debugger.  One of the best 
> I have ever used.  Feature rich.  Lots of powerful debugging 
> features, in addition to full flash programming.
>   >
>   >Moreover, I can control which areas of flash get 
> reprogrammed.  That has turned out to be very useful.  
> Sometimes I do not want data areas to be changed when I 
> reload the code.  So I skip those address ranges.  Very handy.
>   >
>   >Chris.
>   >
>   >
>   >
>   >
>   >  ----- Original Message -----
>   >  From: Michael Johnson
>   >  To: lpc2000@yahoogroups.com
>   >  Sent: Monday, September 26, 2005 10:42 PM
>   >  Subject: Re: [lpc2000] Slow OCD Remote/Insight debugging
>   >
>   >
>   >  Does 1M==1Mbyte or 128Kbyte? Which LPC21xx device are 
> you using? Are you
>   >  downloading into flash? How long does it take for you to 
> download 64K
>   >  bytes into the flash of an LPC21xx?
>   >
>   >  Michael
>   >
>   >  >14K Wow.  And I thought the 1M rate I'm getting with 
> the Signum JetJTAG was slow.  I can't imagine doing tons of 
> debuging at 14K.
>   >  >
>   >  >Chris.
>   >  >
>   >  >
>   >  >  ----- Original Message -----
>   >  >  From: Michael Johnson
>   >  >  To: lpc2000@yahoogroups.com
>   >  >  Sent: Monday, September 26, 2005 5:58 AM
>   >  >  Subject: Re: [lpc2000] Slow OCD Remote/Insight debugging
>   >  >
>   >  >
>   >  >  We've found that you can't drive the signals on a PC 
> parallel port at
>   >  >  more than 4kHz (this is in GPIO/bit bang mode - 
> EPP/ECP is a different
>   >  >  tale). Even with this limitation CrossWorks for ARM 
> has a flash download
>   >  >  speed of 14Kbytes per second to the LPC21xx.
>   >  >
>   >  >  Michael
>   >  >
>   >  >  >And what would that be?  I thought that a download 
> of the OCD app from the same people who make the hardware 
> should likely work.  I can understand some really limited 
> features, but a 4kHz connection speed? That really surprised me.
>   >  >  >
>   >  >  >Chris.
>   >  >  >
>   >  >  >  ----- Original Message -----
>   >  >  >  From: Michael Johnson
>   >  >  >  To: lpc2000@yahoogroups.com
>   >  >  >  Sent: Monday, September 26, 2005 4:37 AM
>   >  >  >  Subject: Re: [lpc2000] Slow OCD Remote/Insight debugging
>   >  >  >
>   >  >  >
>   >  >  >  Wigglers work - you just have to choose (perhaps 
> even buy) the
>   >  >  >  appropriate software to drive them.
>   >  >  >
>   >  >  >  Michael
>   >  >  >
>   >  >  >  >I saw the same problem with the wiggler.  Had 
> problems connecting to my LPC2104 at anything but really low 
> speeds.  The OCD is not a professional level debugger.  In 
> order to debug a program that you intend to run in FLASH, you 
> have to download your program into FLASH.  OCD can't do this.
>   >  >  >  >
>   >  >  >  >I bought a Signum JTAGJet and it is worth it. It 
> downloads and programs to flash, as well as having a superb 
> C/ASM debugger.   I use the GNUARM for compiling, but I much 
> prefer a professional debugger.
>   >  >  >  >
>   >  >  >  >Chris.
>   >  >  >  >
>   >  >  >  >
>   >  >  >  >  ----- Original Message -----
>   >  >  >  >  From: Blagoj Kupev
>   >  >  >  >  To: lpc2000@yahoogroups.com
>   >  >  >  >  Sent: Monday, September 26, 2005 12:09 AM
>   >  >  >  >  Subject: [lpc2000] Slow OCD Remote/Insight debugging
>   >  >  >  >
>   >  >  >  >
>   >  >  >  >  Hi there,
>   >  >  >  >
>   >  >  >  >  I'm beginner in ARM7 world and everything looks 
> strange to me. I've
>   >  >  >  >  build wiggler compatible interface and i have 
> MCB2130 from Keil. I have
>   >  >  >  >  few questions regarding debuging:
>   >  >  >  >  1. Why OCD Remote/Insight combination works 10 
> times slower compared to
>   >  >  >  >  debug speed when i try to debug same SW using 
> Rowley's Cross Studio? (i can not
>   >  >  >  >  connect OCD Remote with speed parameter lower than 3).
>   >  >  >  >  2. I found some discussion but still it is not 
> clear to me if i can
>   >  >  >  >  debug sw in flash with OCD Remote? I read that 
> OCD Remote does not
>   >  >  >  >  support hardware breakpoints that is requred 
> for debugging in flash. Is
>   >  >  >  >  this true or i'm missing something?
>   >  >  >  >  Best regards,
>   >  >  >  >  Blagoj
>   >  >  >  >
>   >  >  >  >
>   >  >  >  >
>   >  >  >  >
>   >  >  >  >  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]
>   >  >  >  >
>   >  >  >  >
>   >  >  >  >
>   >  >  >  >
>   >  >  >  >
>   >  >  >  >Yahoo! Groups Links
>   >  >  >  >
>   >  >  >  >
>   >  >  >  >
>   >  >  >  >
>   >  >  >  >
>   >  >  >  >
>   >  >  >  >
>   >  >  >  >
>   >  >  >  >
>   >  >  >
>   >  >  >
>   >  >  >
>   >  >  
> >-------------------------------------------------------------
> -----------------
>   >  >  >  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]
>   >  >  >
>   >  >  >
>   >  >  >
>   >  >  >
>   >  >  >
>   >  >  >Yahoo! Groups Links
>   >  >  >
>   >  >  >
>   >  >  >
>   >  >  >
>   >  >  >
>   >  >  >
>   >  >  >
>   >  >  >
>   >  >
>   >  >
>   >  >
>   >  >  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]
>   >  >
>   >  >
>   >  >
>   >  >
>   >  >
>   >  >Yahoo! Groups Links
>   >  >
>   >  >
>   >  >
>   >  >
>   >  >
>   >  >
>   >  >
>   >  >
>   >
>   >
>   >
>   >  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]
>   >
>   >
>   >
>   >
>   >
>   >Yahoo! Groups Links
>   >
>   >
>   >
>   >
>   >
>   >
>   >
>   >
> 
> 
> 
>   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]
> 
> 
> 
> ------------------------ Yahoo! Groups Sponsor 
> --------------------~--> Get Bzzzy! (real tools to help you 
> find a job). Welcome to the Sweet Life.
> http://us.click.yahoo.com/A77XvD/vlQLAA/TtwFAA/dN_tlB/TM
> --------------------------------------------------------------
> ------~-> 
> 
>  
> Yahoo! Groups Links
> 
> 
> 
>  
> 
> 
> 
>

Re: [lpc2000] Slow OCD Remote/Insight debugging

2005-09-28 by Blagoj Kupev

As i understand regarding your comments it is much cost effective that i 
buy CrossConnect with CrossWorks than to by Seggers JTAGjet?! What about 
support from their vendors? I've heard good thoughts about Rowley, what 
about Segger?
Regards,
Blagoj


Na 26.09.2005 09:09 Blagoj Kupev rece:
Show quoted textHide quoted text
>Hi there,
>
>I'm beginner in ARM7 world and everything looks strange to me. I've 
>build wiggler compatible interface and i have MCB2130 from Keil. I have 
>few questions regarding debuging:
>1. Why OCD Remote/Insight combination works 10 times slower compared to 
>debug speed when i try to debug same SW using Rowley's Cross Studio? (i can not 
>connect OCD Remote with speed parameter lower than 3).
>2. I found some discussion but still it is not clear to me if i can 
>debug sw in flash with OCD Remote? I read that OCD Remote does not 
>support hardware breakpoints that is requred for debugging in flash. Is 
>this true or i'm missing something?
>Best regards,
>Blagoj
>
>
>
>
>
> 
>Yahoo! Groups Links
>
>
>
> 
>
>
>
>__________ NOD32 1.1232 (20050925) Information __________
>
>This message was checked by NOD32 antivirus system.
>http://www.eset.com
>
>
>
>  
>

Re: [lpc2000] Slow OCD Remote/Insight debugging

2005-09-28 by sig5534@hotmail.com

I guess you missed the point.  The programming time is limited by the internal operation of the LPC CPU.  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.

Chris.
Show quoted textHide quoted text
  ----- Original Message ----- 
  From: Paul Curtis 
  To: lpc2000@yahoogroups.com 
  Sent: Wednesday, September 28, 2005 4:41 AM
  Subject: RE: [lpc2000] Slow OCD Remote/Insight debugging


  Hi, 

  > The time is all due to the erase I think.  As I recall it 
  > takes about 0.3 Sec per sector and there are about 16 
  > sectors, so that is about 5 seconds right there.   Normally 
  > the defaut is to erase the entire part and that is what takes 
  > a few seconds.   My code on this one part right now is about 
  > 48K.  Moving the data doesn't take anytime at all.  It's 
  > waiting for the slow internal LPC flash processing.

  Ok, so 48K in 6 seconds is 8K per second to download and flash.  Gee.
  That's way slower than CrossWorks' wiggler implementation which will
  erase, download, and flash at 14KB per second on an LPC.  The
  CrossConnect will download and flash at 34K per second on an LPC.  So,
  if you have 48K, the CrossConnect will erase, download, and complete
  flashing within 2s 2s of hitting the Go button.

  Seems like the JTAGjet isn't quick so "jet" after all.

  -- Paul.

  > 
  > Chris.
  > 
  >   ----- Original Message -----
  >   From: Michael Johnson
  >   To: lpc2000@yahoogroups.com
  >   Sent: Tuesday, September 27, 2005 11:26 PM
  >   Subject: Re: [lpc2000] Slow OCD Remote/Insight debugging
  > 
  > 
  > 
  >   >I mean 1 MegaByte per second.  That is my JTAG link speed. 
  >  I have 2 designs right now I am working with, a LPC2106 and 
  > an LPC2124.  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 
  > limitations of the flash erase and programming.  My code is 
  > too big to run in RAM.  All my code must be run from flash.
  >   >
  >   >
  >   What is the size of your program that takes 6 seconds to 
  > download to flash?
  > 
  >   Michael
  > 
  >   >But the biggest difference is the Chameleon debugger of 
  > Signum.  That OCD is a joke, its not even a debugger, and the 
  > GNU Insight debugger ain't much better.  With Chameleon I can 
  > watch so many more things going on inside the CPU and it even 
  > breaks apart record structures and gives me the value on 
  > anything anytime I want, anywhere in my code.  Full display 
  > of both C and ASM real time, with both hardware and software 
  > breakpoints.  It is a top quality debugger.  One of the best 
  > I have ever used.  Feature rich.  Lots of powerful debugging 
  > features, in addition to full flash programming.
  >   >
  >   >Moreover, I can control which areas of flash get 
  > reprogrammed.  That has turned out to be very useful.  
  > Sometimes I do not want data areas to be changed when I 
  > reload the code.  So I skip those address ranges.  Very handy.
  >   >
  >   >Chris.
  >   >
  >   >
  >   >
  >   >
  >   >  ----- Original Message -----
  >   >  From: Michael Johnson
  >   >  To: lpc2000@yahoogroups.com
  >   >  Sent: Monday, September 26, 2005 10:42 PM
  >   >  Subject: Re: [lpc2000] Slow OCD Remote/Insight debugging
  >   >
  >   >
  >   >  Does 1M==1Mbyte or 128Kbyte? Which LPC21xx device are 
  > you using? Are you
  >   >  downloading into flash? How long does it take for you to 
  > download 64K
  >   >  bytes into the flash of an LPC21xx?
  >   >
  >   >  Michael
  >   >
  >   >  >14K Wow.  And I thought the 1M rate I'm getting with 
  > the Signum JetJTAG was slow.  I can't imagine doing tons of 
  > debuging at 14K.
  >   >  >
  >   >  >Chris.
  >   >  >
  >   >  >
  >   >  >  ----- Original Message -----
  >   >  >  From: Michael Johnson
  >   >  >  To: lpc2000@yahoogroups.com
  >   >  >  Sent: Monday, September 26, 2005 5:58 AM
  >   >  >  Subject: Re: [lpc2000] Slow OCD Remote/Insight debugging
  >   >  >
  >   >  >
  >   >  >  We've found that you can't drive the signals on a PC 
  > parallel port at
  >   >  >  more than 4kHz (this is in GPIO/bit bang mode - 
  > EPP/ECP is a different
  >   >  >  tale). Even with this limitation CrossWorks for ARM 
  > has a flash download
  >   >  >  speed of 14Kbytes per second to the LPC21xx.
  >   >  >
  >   >  >  Michael
  >   >  >
  >   >  >  >And what would that be?  I thought that a download 
  > of the OCD app from the same people who make the hardware 
  > should likely work.  I can understand some really limited 
  > features, but a 4kHz connection speed? That really surprised me.
  >   >  >  >
  >   >  >  >Chris.
  >   >  >  >
  >   >  >  >  ----- Original Message -----
  >   >  >  >  From: Michael Johnson
  >   >  >  >  To: lpc2000@yahoogroups.com
  >   >  >  >  Sent: Monday, September 26, 2005 4:37 AM
  >   >  >  >  Subject: Re: [lpc2000] Slow OCD Remote/Insight debugging
  >   >  >  >
  >   >  >  >
  >   >  >  >  Wigglers work - you just have to choose (perhaps 
  > even buy) the
  >   >  >  >  appropriate software to drive them.
  >   >  >  >
  >   >  >  >  Michael
  >   >  >  >
  >   >  >  >  >I saw the same problem with the wiggler.  Had 
  > problems connecting to my LPC2104 at anything but really low 
  > speeds.  The OCD is not a professional level debugger.  In 
  > order to debug a program that you intend to run in FLASH, you 
  > have to download your program into FLASH.  OCD can't do this.
  >   >  >  >  >
  >   >  >  >  >I bought a Signum JTAGJet and it is worth it. It 
  > downloads and programs to flash, as well as having a superb 
  > C/ASM debugger.   I use the GNUARM for compiling, but I much 
  > prefer a professional debugger.
  >   >  >  >  >
  >   >  >  >  >Chris.
  >   >  >  >  >
  >   >  >  >  >
  >   >  >  >  >  ----- Original Message -----
  >   >  >  >  >  From: Blagoj Kupev
  >   >  >  >  >  To: lpc2000@yahoogroups.com
  >   >  >  >  >  Sent: Monday, September 26, 2005 12:09 AM
  >   >  >  >  >  Subject: [lpc2000] Slow OCD Remote/Insight debugging
  >   >  >  >  >
  >   >  >  >  >
  >   >  >  >  >  Hi there,
  >   >  >  >  >
  >   >  >  >  >  I'm beginner in ARM7 world and everything looks 
  > strange to me. I've
  >   >  >  >  >  build wiggler compatible interface and i have 
  > MCB2130 from Keil. I have
  >   >  >  >  >  few questions regarding debuging:
  >   >  >  >  >  1. Why OCD Remote/Insight combination works 10 
  > times slower compared to
  >   >  >  >  >  debug speed when i try to debug same SW using 
  > Rowley's Cross Studio? (i can not
  >   >  >  >  >  connect OCD Remote with speed parameter lower than 3).
  >   >  >  >  >  2. I found some discussion but still it is not 
  > clear to me if i can
  >   >  >  >  >  debug sw in flash with OCD Remote? I read that 
  > OCD Remote does not
  >   >  >  >  >  support hardware breakpoints that is requred 
  > for debugging in flash. Is
  >   >  >  >  >  this true or i'm missing something?
  >   >  >  >  >  Best regards,
  >   >  >  >  >  Blagoj
  >   >  >  >  >
  >   >  >  >  >
  >   >  >  >  >
  >   >  >  >  >
  >   >  >  >  >  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]
  >   >  >  >  >
  >   >  >  >  >
  >   >  >  >  >
  >   >  >  >  >
  >   >  >  >  >
  >   >  >  >  >Yahoo! Groups Links
  >   >  >  >  >
  >   >  >  >  >
  >   >  >  >  >
  >   >  >  >  >
  >   >  >  >  >
  >   >  >  >  >
  >   >  >  >  >
  >   >  >  >  >
  >   >  >  >  >
  >   >  >  >
  >   >  >  >
  >   >  >  >
  >   >  >  
  > >-------------------------------------------------------------
  > -----------------
  >   >  >  >  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]
  >   >  >  >
  >   >  >  >
  >   >  >  >
  >   >  >  >
  >   >  >  >
  >   >  >  >Yahoo! Groups Links
  >   >  >  >
  >   >  >  >
  >   >  >  >
  >   >  >  >
  >   >  >  >
  >   >  >  >
  >   >  >  >
  >   >  >  >
  >   >  >
  >   >  >
  >   >  >
  >   >  >  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]
  >   >  >
  >   >  >
  >   >  >
  >   >  >
  >   >  >
  >   >  >Yahoo! Groups Links
  >   >  >
  >   >  >
  >   >  >
  >   >  >
  >   >  >
  >   >  >
  >   >  >
  >   >  >
  >   >
  >   >
  >   >
  >   >  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]
  >   >
  >   >
  >   >
  >   >
  >   >
  >   >Yahoo! Groups Links
  >   >
  >   >
  >   >
  >   >
  >   >
  >   >
  >   >
  >   >
  > 
  > 
  > 
  >   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]
  > 
  > 
  > 
  > ------------------------ Yahoo! Groups Sponsor 
  > --------------------~--> Get Bzzzy! (real tools to help you 
  > find a job). Welcome to the Sweet Life.
  > http://us.click.yahoo.com/A77XvD/vlQLAA/TtwFAA/dN_tlB/TM
  > --------------------------------------------------------------
  > ------~-> 
  > 
  >  
  > Yahoo! Groups Links
  > 
  > 
  > 
  >  
  > 
  > 
  > 
  > 


  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]

RE: [lpc2000] Slow OCD Remote/Insight debugging

2005-09-28 by Paul Curtis

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.

Re: [lpc2000] Slow OCD Remote/Insight debugging

2005-09-28 by Matthias Hertel

You do flash programming at 1MB/s on an LPC2xxx controller?
Show quoted textHide quoted text
> 14K Wow.  And I thought the 1M rate I'm getting with the Signum 
> JetJTAG was slow.  I can't imagine doing tons of debuging at 14K.
>
> Chris.
>
>
>   ----- Original Message -----
>   From: Michael Johnson
>   To: lpc2000@yahoogroups.com
>   Sent: Monday, September 26, 2005 5:58 AM
>   Subject: Re: [lpc2000] Slow OCD Remote/Insight debugging
>
>
>   We've found that you can't drive the signals on a PC parallel port at
>   more than 4kHz (this is in GPIO/bit bang mode - EPP/ECP is a different
>   tale). Even with this limitation CrossWorks for ARM has a flash 
> download
>   speed of 14Kbytes per second to the LPC21xx.
>
>   Michael
>
>   >And what would that be?  I thought that a download of the OCD app 
> from the same people who make the hardware should likely work.  I can 
> understand some really limited features, but a 4kHz connection speed? 
> That really surprised me.
>   >
>   >Chris.
>   >
>   >  ----- Original Message -----
>   >  From: Michael Johnson
>   >  To: lpc2000@yahoogroups.com
>   >  Sent: Monday, September 26, 2005 4:37 AM
>   >  Subject: Re: [lpc2000] Slow OCD Remote/Insight debugging
>   >
>   >
>   >  Wigglers work - you just have to choose (perhaps even buy) the
>   >  appropriate software to drive them.
>   >
>   >  Michael
>   >
>   >  >I saw the same problem with the wiggler.  Had problems 
> connecting to my LPC2104 at anything but really low speeds.  The OCD 
> is not a professional level debugger.  In order to debug a program 
> that you intend to run in FLASH, you have to download your program 
> into FLASH.  OCD can't do this.
>   >  >
>   >  >I bought a Signum JTAGJet and it is worth it. It downloads and 
> programs to flash, as well as having a superb C/ASM debugger.   I use 
> the GNUARM for compiling, but I much prefer a professional debugger.
>   >  >
>   >  >Chris.
>   >  >
>   >  >
>   >  >  ----- Original Message -----
>   >  >  From: Blagoj Kupev
>   >  >  To: lpc2000@yahoogroups.com
>   >  >  Sent: Monday, September 26, 2005 12:09 AM
>   >  >  Subject: [lpc2000] Slow OCD Remote/Insight debugging
>   >  >
>   >  >
>   >  >  Hi there,
>   >  >
>   >  >  I'm beginner in ARM7 world and everything looks strange to me. 
> I've
>   >  >  build wiggler compatible interface and i have MCB2130 from 
> Keil. I have
>   >  >  few questions regarding debuging:
>   >  >  1. Why OCD Remote/Insight combination works 10 times slower 
> compared to
>   >  >  debug speed when i try to debug same SW using Rowley's Cross 
> Studio? (i can not
>   >  >  connect OCD Remote with speed parameter lower than 3).
>   >  >  2. I found some discussion but still it is not clear to me if 
> i can
>   >  >  debug sw in flash with OCD Remote? I read that OCD Remote does 
> not
>   >  >  support hardware breakpoints that is requred for debugging in 
> flash. Is
>   >  >  this true or i'm missing something?
>   >  >  Best regards,
>   >  >  Blagoj
>   >  >
>   >  >
>   >  >
>   >  >
>   >  >  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]
>   >  >
>   >  >
>   >  >
>   >  >
>   >  >
>   >  >Yahoo! Groups Links
>   >  >
>   >  >
>   >  >
>   >  >
>   >  >
>   >  >
>   >  >
>   >  > 
>   >  >
>   >
>   >
>   >
>   
> >------------------------------------------------------------------------------
>   >  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]
>   >
>   >
>   >
>   >
>   >
>   >Yahoo! Groups Links
>   >
>   >
>   >
>   >
>   >
>   >
>   > 
>   >
>
>
>
>   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]
>
>
> ------------------------------------------------------------------------
> YAHOO! GROUPS LINKS
>
>     *  Visit your group "lpc2000
>       <http://groups.yahoo.com/group/lpc2000>" on the web.
>        
>     *  To unsubscribe from this group, send an email to:
>        lpc2000-unsubscribe@yahoogroups.com
>       <mailto:lpc2000-unsubscribe@yahoogroups.com?subject=Unsubscribe>
>        
>     *  Your use of Yahoo! Groups is subject to the Yahoo! Terms of
>       Service <http://docs.yahoo.com/info/terms/>.
>
>
> ------------------------------------------------------------------------
>

Re: [lpc2000] Slow OCD Remote/Insight debugging

2005-09-29 by Blagoj Kupev

Here is my opinion using other MCUs (MPC565, PIC16F, PIC18F) and i think 
for LPC the situation is the same regarding programming speeds. There 
are two different speeds, one is speed of internal flash module and 
other is speed of communication PC to Target MCU. Normally when flash 
erase is started speed of erase depends mostly on the speed of flash 
module and not on the speed of interface.
But programming of RAM mostly depends on speed of interface since RAM 
modules are much, much faster than flash modules.
It is good if both of you can test your interfaces on same target MCU 
but with biggest elf file that can be fitted inside flash and/or ram of 
target mcu. This way tests will be performed on same mcu and difference 
will be only on speed of interface and a bit on speed of used PC. This 
way we'll see it JTAGjet really has "jet" spped compared to CrossConnect.
Regards,
Blagoj


Na 28.09.2005 17:21 Paul Curtis rece:
Show quoted textHide quoted text
>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.
>
>
>
>
>
>
> 
>Yahoo! Groups Links
>
>
>
> 
>
>
>
>__________ NOD32 1.1236 (20050928) Information __________
>
>This message was checked by NOD32 antivirus system.
>http://www.eset.com
>
>
>
>  
>

Re: [lpc2000] Slow OCD Remote/Insight debugging

2005-09-29 by sig5534@hotmail.com

That is the JTAG link speed setting.  Actual the probe goes to 10M but the LPC would not take that.

Chris.
Show quoted textHide quoted text
----- Original Message ----- 
  From: Matthias Hertel 
  To: lpc2000@yahoogroups.com 
  Sent: Wednesday, September 28, 2005 9:33 AM
  Subject: Re: [lpc2000] Slow OCD Remote/Insight debugging


  You do flash programming at 1MB/s on an LPC2xxx controller?

  > 14K Wow.  And I thought the 1M rate I'm getting with the Signum 
  > JetJTAG was slow.  I can't imagine doing tons of debuging at 14K.
  >
  > Chris.
  >
  >
  >   ----- Original Message -----
  >   From: Michael Johnson
  >   To: lpc2000@yahoogroups.com
  >   Sent: Monday, September 26, 2005 5:58 AM
  >   Subject: Re: [lpc2000] Slow OCD Remote/Insight debugging
  >
  >
  >   We've found that you can't drive the signals on a PC parallel port at
  >   more than 4kHz (this is in GPIO/bit bang mode - EPP/ECP is a different
  >   tale). Even with this limitation CrossWorks for ARM has a flash 
  > download
  >   speed of 14Kbytes per second to the LPC21xx.
  >
  >   Michael
  >
  >   >And what would that be?  I thought that a download of the OCD app 
  > from the same people who make the hardware should likely work.  I can 
  > understand some really limited features, but a 4kHz connection speed? 
  > That really surprised me.
  >   >
  >   >Chris.
  >   >
  >   >  ----- Original Message -----
  >   >  From: Michael Johnson
  >   >  To: lpc2000@yahoogroups.com
  >   >  Sent: Monday, September 26, 2005 4:37 AM
  >   >  Subject: Re: [lpc2000] Slow OCD Remote/Insight debugging
  >   >
  >   >
  >   >  Wigglers work - you just have to choose (perhaps even buy) the
  >   >  appropriate software to drive them.
  >   >
  >   >  Michael
  >   >
  >   >  >I saw the same problem with the wiggler.  Had problems 
  > connecting to my LPC2104 at anything but really low speeds.  The OCD 
  > is not a professional level debugger.  In order to debug a program 
  > that you intend to run in FLASH, you have to download your program 
  > into FLASH.  OCD can't do this.
  >   >  >
  >   >  >I bought a Signum JTAGJet and it is worth it. It downloads and 
  > programs to flash, as well as having a superb C/ASM debugger.   I use 
  > the GNUARM for compiling, but I much prefer a professional debugger.
  >   >  >
  >   >  >Chris.
  >   >  >
  >   >  >
  >   >  >  ----- Original Message -----
  >   >  >  From: Blagoj Kupev
  >   >  >  To: lpc2000@yahoogroups.com
  >   >  >  Sent: Monday, September 26, 2005 12:09 AM
  >   >  >  Subject: [lpc2000] Slow OCD Remote/Insight debugging
  >   >  >
  >   >  >
  >   >  >  Hi there,
  >   >  >
  >   >  >  I'm beginner in ARM7 world and everything looks strange to me. 
  > I've
  >   >  >  build wiggler compatible interface and i have MCB2130 from 
  > Keil. I have
  >   >  >  few questions regarding debuging:
  >   >  >  1. Why OCD Remote/Insight combination works 10 times slower 
  > compared to
  >   >  >  debug speed when i try to debug same SW using Rowley's Cross 
  > Studio? (i can not
  >   >  >  connect OCD Remote with speed parameter lower than 3).
  >   >  >  2. I found some discussion but still it is not clear to me if 
  > i can
  >   >  >  debug sw in flash with OCD Remote? I read that OCD Remote does 
  > not
  >   >  >  support hardware breakpoints that is requred for debugging in 
  > flash. Is
  >   >  >  this true or i'm missing something?
  >   >  >  Best regards,
  >   >  >  Blagoj
  >   >  >
  >   >  >
  >   >  >
  >   >  >
  >   >  >  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]
  >   >  >
  >   >  >
  >   >  >
  >   >  >
  >   >  >
  >   >  >Yahoo! Groups Links
  >   >  >
  >   >  >
  >   >  >
  >   >  >
  >   >  >
  >   >  >
  >   >  >
  >   >  > 
  >   >  >
  >   >
  >   >
  >   >
  >   
  > >------------------------------------------------------------------------------
  >   >  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]
  >   >
  >   >
  >   >
  >   >
  >   >
  >   >Yahoo! Groups Links
  >   >
  >   >
  >   >
  >   >
  >   >
  >   >
  >   > 
  >   >
  >
  >
  >
  >   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]
  >
  >
  > ------------------------------------------------------------------------
  > YAHOO! GROUPS LINKS
  >
  >     *  Visit your group "lpc2000
  >       <http://groups.yahoo.com/group/lpc2000>" on the web.
  >        
  >     *  To unsubscribe from this group, send an email to:
  >        lpc2000-unsubscribe@yahoogroups.com
  >       <mailto:lpc2000-unsubscribe@yahoogroups.com?subject=Unsubscribe>
  >        
  >     *  Your use of Yahoo! Groups is subject to the Yahoo! Terms of
  >       Service <http://docs.yahoo.com/info/terms/>.
  >
  >
  > ------------------------------------------------------------------------
  >



  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]

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.
Show quoted textHide quoted text
  ----- 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]

RE: [lpc2000] Slow OCD Remote/Insight debugging

2005-09-30 by Paul Curtis

Chris, 

> 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.

You just don't seem to understand.  14K is the flashing rate in bytes
per second and has nothing to do with your "1M rate" which is bits per
second on TDI/TDO and clocking the JTAG state machine  If I told you
that the CrossConnect actually runs a 4MHz clock on TCK that's faster
than your 1M rate isn't it?

You're comparing apples with oranges.  Until you can understand that we
can write data into RAM at 200Kbytes/second (that equates to
1.6Mbit/second), you're just not going to grasp that these pieces of
hardware are comparible and, as far as I can tell form what you've said,
the CrossConnect is faster.

-- Paul.

Re: Slow OCD Remote/Insight debugging

2005-10-01 by John Heenan

The Signum JTAGjet claims download speed in excess of 1 MByte/sec, 
not 1Mbit/sec. From the Signum web site 
http://www.signum.com/Signum.htm 
"Actual speed 1.062 Mbyte/sec tested with ARM Evaluator 7T board and 
600 MHz Pentium III PC with USB 2.0 port. Faster PCs may yield faster 
downloads."

Since the JTAGjet uses USB 2.0 this is reasonable, provivded the 
target device and connections can hold up.

Leaving aside the issue of delays introduced by programming Flash, 
which many developers do not need to bother with during development 
if all their code fits into RAM, the claimed speed supports what many 
developers welcome and which was mentioned by Chris: rapid reading of 
data blocks at breakpoints.

The Signum JTAGjet also claims compatibility with all major ARM 
debuggers and another version of the JTAGjet supports ETM.

I am simply pointing out factual issues. This is what I welcome from 
a newsgroup, along with a balance of relevance and fair 
represenstation. 

John Heenan


--- In lpc2000@yahoogroups.com, "Paul Curtis" <plc@r...> wrote:
> Chris, 
> 
> > 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.
> 
> You just don't seem to understand.  14K is the flashing rate in 
bytes
> per second and has nothing to do with your "1M rate" which is bits 
per
> second on TDI/TDO and clocking the JTAG state machine  If I told you
> that the CrossConnect actually runs a 4MHz clock on TCK that's 
faster
> than your 1M rate isn't it?
> 
> You're comparing apples with oranges.  Until you can understand 
that we
> can write data into RAM at 200Kbytes/second (that equates to
> 1.6Mbit/second), you're just not going to grasp that these pieces of
> hardware are comparible and, as far as I can tell form what you've 
said,
Show quoted textHide quoted text
> the CrossConnect is faster.
> 
> -- Paul.

Re: [lpc2000] Re: Slow OCD Remote/Insight debugging

2005-10-02 by Rob Jansen

Incredible download speeds ...
If I have to download 64 kB to RAM for running (or flash programming) 
the wiggler will do this in 4 secs, the JTAGjet in 0.0000... secs. After 
this I spend at least 1800 secs to step through my program for debugging 
and most of this time I will just look at what happened with a 
flabbergasted look on my face :-) So I am not that concerned with 
download speed. I am used to debugging a system with a 204 MHz ARM926 
and a megabyte-or-so image using a RealView ICE. Downloading takes a few 
secs but stepping through my code is fast - even if I have some watches 
out there that do contain large data arrays (something you really want 
to avoid).

Hence download speed and flashing memory is not my concern but reading 
(preferably) small pieces of RAM after every step is. How fast can you 
step through the code with your debugger, do you see any real delays or 
can you just step at (full speed) 2 key/mouseclicks per seconds?

Rob

John Heenan wrote:
Show quoted textHide quoted text
> The Signum JTAGjet claims download speed in excess of 1 MByte/sec,
> not 1Mbit/sec. From the Signum web site
> http://www.signum.com/Signum.htm
> "Actual speed 1.062 Mbyte/sec tested with ARM Evaluator 7T board and
> 600 MHz Pentium III PC with USB 2.0 port. Faster PCs may yield faster
> downloads."

Re: [lpc2000] Re: Slow OCD Remote/Insight debugging

2005-10-02 by Michael Johnson

John Heenan wrote:

>The Signum JTAGjet claims download speed in excess of 1 MByte/sec, 
>not 1Mbit/sec. From the Signum web site 
>http://www.signum.com/Signum.htm 
>"Actual speed 1.062 Mbyte/sec tested with ARM Evaluator 7T board and 
>600 MHz Pentium III PC with USB 2.0 port. Faster PCs may yield faster 
>downloads."
>
>Since the JTAGjet uses USB 2.0 this is reasonable, provivded the 
>target device and connections can hold up.
>
>Leaving aside the issue of delays introduced by programming Flash, 
>which many developers do not need to bother with during development 
>if all their code fits into RAM, the claimed speed supports what many 
>developers welcome and which was mentioned by Chris: rapid reading of 
>data blocks at breakpoints.
>
>The Signum JTAGjet also claims compatibility with all major ARM 
>debuggers and another version of the JTAGjet supports ETM.
>  
>
What's a major debugger?

>I am simply pointing out factual issues. This is what I welcome from 
>a newsgroup, along with a balance of relevance and fair 
>represenstation. 
>  
>
The LPC22xx could be used to run programs from an external SRAM - this 
is an approach that can be used to avoid the two breakpoints limitation. 
It would be useful for someone who has this hardware combination (Signum 
JTAGjet and LPC22xx+SRAM) to provide download (and upload) figures.

Michael
Show quoted textHide quoted text
>John Heenan
>
>
>--- In lpc2000@yahoogroups.com, "Paul Curtis" <plc@r...> wrote:
>  
>
>>Chris, 
>>
>>    
>>
>>>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.
>>>      
>>>
>>You just don't seem to understand.  14K is the flashing rate in 
>>    
>>
>bytes
>  
>
>>per second and has nothing to do with your "1M rate" which is bits 
>>    
>>
>per
>  
>
>>second on TDI/TDO and clocking the JTAG state machine  If I told you
>>that the CrossConnect actually runs a 4MHz clock on TCK that's 
>>    
>>
>faster
>  
>
>>than your 1M rate isn't it?
>>
>>You're comparing apples with oranges.  Until you can understand 
>>    
>>
>that we
>  
>
>>can write data into RAM at 200Kbytes/second (that equates to
>>1.6Mbit/second), you're just not going to grasp that these pieces of
>>hardware are comparible and, as far as I can tell form what you've 
>>    
>>
>said,
>  
>
>>the CrossConnect is faster.
>>
>>-- Paul.
>>    
>>
>
>
>
>
>
> 
>Yahoo! Groups Links
>
>
>
> 
>
>
>  
>

Re: [lpc2000] Re: Slow OCD Remote/Insight debugging

2005-10-02 by Michael Johnson

Rob Jansen wrote:

>Incredible download speeds ...
>If I have to download 64 kB to RAM for running (or flash programming) 
>the wiggler will do this in 4 secs, the JTAGjet in 0.0000... secs. After 
>this I spend at least 1800 secs to step through my program for debugging 
>and most of this time I will just look at what happened with a 
>flabbergasted look on my face :-) So I am not that concerned with 
>download speed. I am used to debugging a system with a 204 MHz ARM926 
>and a megabyte-or-so image using a RealView ICE. Downloading takes a few 
>secs but stepping through my code is fast - even if I have some watches 
>out there that do contain large data arrays (something you really want 
>to avoid).
>
>Hence download speed and flashing memory is not my concern but reading 
>(preferably) small pieces of RAM after every step is. How fast can you 
>step through the code with your debugger, do you see any real delays or 
>can you just step at (full speed) 2 key/mouseclicks per seconds?
>  
>
Stepping performance is fine with both wiggler and CrossConnect. 
Wigglers work remarkably well in this area since there are no comms 
latencies and the CrossConnect is fast at everything. We don't have any 
figures for uploading - we'll correct this when we update our 
wiggler/CrossConnect performance figures.

Michael
Show quoted textHide quoted text
>Rob
>
>John Heenan wrote:
>
>  
>
>>The Signum JTAGjet claims download speed in excess of 1 MByte/sec,
>>not 1Mbit/sec. From the Signum web site
>>http://www.signum.com/Signum.htm
>>"Actual speed 1.062 Mbyte/sec tested with ARM Evaluator 7T board and
>>600 MHz Pentium III PC with USB 2.0 port. Faster PCs may yield faster
>>downloads."
>>    
>>
>
>
>
>
>
> 
>Yahoo! Groups Links
>
>
>
> 
>
>
>  
>

RE: [lpc2000] Re: Slow OCD Remote/Insight debugging

2005-10-02 by Paul Curtis

John, 

> The Signum JTAGjet claims download speed in excess of 1 
> MByte/sec, not 1Mbit/sec.

You can't get anywhere near that on ARM7TDMI-S parts which we are
dicussing, so this claimed speed is irrelevant in this instance.

> From the Signum web site 
> http://www.signum.com/Signum.htm "Actual speed 1.062 
> Mbyte/sec tested with ARM Evaluator 7T board and 600 MHz 
> Pentium III PC with USB 2.0 port. Faster PCs may yield faster 
> downloads."

Yes, the Evaluator-7T is a hard core and TCK can be clocked at 10MHz in
this case (or greater in some cases).  However, not all ARM parts
support this.

> Since the JTAGjet uses USB 2.0 this is reasonable, provivded 
> the target device and connections can hold up.

USB 2.0 conformance does not imply a high speed device.  CrossConnect is
a USB 2.0 full speed device. Is the JTAGjet a full speed or high speed
device?  Or are you making the assumption that all USB 2.0 devices are
high speed and equating 2.0 devices to be inherently faster than 1.1
devices?  USB 1.1 full speed devices can support 1Mbyte/sec data rates
over USB so the statement "Since the JTAGjet uses USB 2.0 this is
reasonable" holds no weight.

> Leaving aside the issue of delays introduced by programming 
> Flash, which many developers do not need to bother with 
> during development if all their code fits into RAM, the 
> claimed speed supports what many developers welcome and which 
> was mentioned by Chris: rapid reading of data blocks at breakpoints.

We are dicussing speed on the LPC2000--which, by definition, people *do*
need to worry about because many devices have limited RAM, no external
bus, but lots of flash (like the 2148, for instance).  The claimed speed
avantage of the JTAGjet is put to the test in this instance and is below
even the lowly speed of a wiggler.  The original poster said his code
did not fit in RAM and he needed to put in in flash--so the claimed
speed advantage of the JTAGjet is worthless (in this instance).

> The Signum JTAGjet also claims compatibility with all major 
> ARM debuggers and another version of the JTAGjet supports ETM.

...your point?

-- Paul.

Re: [lpc2000] Slow OCD Remote/Insight debugging

2005-10-05 by sig5534@hotmail.com

[You just don't seem to understand.  14K is the flashing rate in bytes
per second and has nothing to do with your "1M rate" which is bits per
second on TDI/TDO and clocking the JTAG state machine  ]

I believe that is what I said isnt it?   Programming time is a different
issue.

[If I told you that the CrossConnect actually runs a 4MHz clock on TCK
that's faster
than your 1M rate isn't it?]

4MHz is higher than 1MHz sure, but the JetJTAG goes up to 10MHz as well.

[You're comparing apples with oranges.  Until you can understand that we
can write data into RAM at 200Kbytes/second (that equates to
1.6Mbit/second), you're just not going to grasp that these pieces of
hardware are comparible and, as far as I can tell form what you've said,
the CrossConnect is faster.]

The discussion that was started began about the Wiggler.  I don't know where
this crossconnect thing came into it.  I know nothing about timings or
performance with that unit.  I don't have one.  I have a JetJTAG and a
Wiggler and that was the point of my comments and comparison.

If you have some other unit and love it, hey I'm happy for you.  But that
has nothing to do with the original post I responded to.

Chris.

Re: [lpc2000] Slow OCD Remote/Insight debugging

2005-10-05 by Michael Johnson

>[You just don't seem to understand.  14K is the flashing rate in bytes
>per second and has nothing to do with your "1M rate" which is bits per
>second on TDI/TDO and clocking the JTAG state machine  ]
>
>I believe that is what I said isnt it?   Programming time is a different
>issue.
>
>[If I told you that the CrossConnect actually runs a 4MHz clock on TCK
>that's faster
>than your 1M rate isn't it?]
>
>4MHz is higher than 1MHz sure, but the JetJTAG goes up to 10MHz as well.
>
>[You're comparing apples with oranges.  Until you can understand that we
>can write data into RAM at 200Kbytes/second (that equates to
>1.6Mbit/second), you're just not going to grasp that these pieces of
>hardware are comparible and, as far as I can tell form what you've said,
>the CrossConnect is faster.]
>
>The discussion that was started began about the Wiggler.  I don't know where
>this crossconnect thing came into it.  I know nothing about timings or
>performance with that unit.  I don't have one.  I have a JetJTAG and a
>Wiggler and that was the point of my comments and comparison.
>
>If you have some other unit and love it, hey I'm happy for you.  But that
>has nothing to do with the original post I responded to.
>  
>
We've also established that a wiggler used with CrossWorks for ARM will 
flash an LPC21xx faster than a JetJTAG.

Michael
Show quoted textHide quoted text
>Chris.
>
>
>
> 
>Yahoo! Groups Links
>
>
>
> 
>
>
>  
>

Re: Slow OCD Remote/Insight debugging

2005-10-06 by John Heenan

--- In lpc2000@yahoogroups.com, "Paul Curtis" <plc@r...> wrote:
> John, 
> 
> > The Signum JTAGjet claims download speed in excess of 1 
> > MByte/sec, not 1Mbit/sec.
> 
> You can't get anywhere near that on ARM7TDMI-S parts which we are
> dicussing, 

Comments below!

> so this claimed speed is irrelevant in this instance.

You made a factual error about the hardware capibility of another 
product in the course of sneering the product. You stated words to 
the effect "Not so jet after all".

First ETM (Embedded Trace Macrocell) is fitted to all LPC2xxxx 
ARM7TDMI-S parts and uses pins independently of JTAG and so TCK. If 
LPC2xxxx parts are happy to support ETM speeds, I don't see why the 
same parts cannot support very high JTAG speeds. Why should one set 
of pins support very high speeds and not another.

Second the JTAG hardware embedded in ARM7TDMI-S parts is not part of 
the core hardware. It monitors the buses and bus signals and is 
clocked independently of the core with the JTAG TCK.

Third the core hardware is hard hardware. Whether the ARM core is 
labelled with S or not for synthesised has nothing to do with the 
speed at which the independent JTAG hardware can be clocked at. While 
I acknowledge non synthesised designed cores have less risk attached 
to them in terms of using proven hardware designs, there is no 
inherent reason why synthesised cores cannot have their JTAGS clocked 
at well over 1Mhz.

I am not an expert on the limiting issues of maximum JTAG TCK 
clocking speeds, however I suspect if there are such issues it is has 
to do with factors independent of the part, which may be simply 
solved. For example using proper speed cabling and including simple 
RC filters to reduce signal crossover at high speeds near part pins.

> > From the Signum web site 
> > http://www.signum.com/Signum.htm "Actual speed 1.062 
> > Mbyte/sec tested with ARM Evaluator 7T board and 600 MHz 
> > Pentium III PC with USB 2.0 port. Faster PCs may yield faster 
> > downloads."
> 
> Yes, the Evaluator-7T is a hard core and TCK can be clocked at 
10MHz in
> this case (or greater in some cases).  However, not all ARM parts
> support this.

Hard core or not is not relevant. See above.

> > Since the JTAGjet uses USB 2.0 this is reasonable, provivded 
> > the target device and connections can hold up.
> 
> USB 2.0 conformance does not imply a high speed device.  
CrossConnect is
> a USB 2.0 full speed device. Is the JTAGjet a full speed or high 
speed
> device?  Or are you making the assumption that all USB 2.0 devices 
are
> high speed and equating 2.0 devices to be inherently faster than 1.1
> devices?  USB 1.1 full speed devices can support 1Mbyte/sec data 
rates
> over USB so the statement "Since the JTAGjet uses USB 2.0 this is
> reasonable" holds no weight.

What are you trying to pull off here?  Of course it holds weight. 
Since the specs mention capibility up to 480Mbits per second then we 
can assume the JTAGjet advertises itself to the USB bus as being able 
to support full USB 2.0 speed and not only that, appears to claim 
capibility of processing the USB speed offered from and to the 
without signalling bottlenecks, if the part allows. Since I don't 
have the USB specs to hand I do not know what the highest average 
speed that USB 2.0 is capable of supporting from the PC side.

> 
> > Leaving aside the issue of delays introduced by programming 
> > Flash, which many developers do not need to bother with 
> > during development if all their code fits into RAM, the 
> > claimed speed supports what many developers welcome and which 
> > was mentioned by Chris: rapid reading of data blocks at 
breakpoints.
> 
> We are dicussing speed on the LPC2000--which, by definition, people 
*do*
> need to worry about because many devices have limited RAM, no 
external
> bus, but lots of flash (like the 2148, for instance).  The claimed 
speed
> avantage of the JTAGjet is put to the test in this instance and is 
below
> even the lowly speed of a wiggler.  The original poster said his 
code
> did not fit in RAM and he needed to put in in flash--so the claimed
> speed advantage of the JTAGjet is worthless (in this instance).
> 

It is helpful if we stick to core issues. There is no monopoly on 
flash programming techniques, which are relatively simple. 
Here is one simple method of programming flash with JTAG that all 
JTAG debuggers can use

1. Download flash programming code to RAM
2. Download a portion of code to be programmed through JTAG to RAM
3. Execute code in RAM to program data previously downloaded to RAM 
to flash

Steps 1 and 2 are influenced by download speed
Step 3 is not influenced by download speed. Step 3 introduces a 
bottleneck that has more of a penalising effect on faster 
downloaders. Whatever flash programming method one device uses, so 
can the other.

> > The Signum JTAGjet also claims compatibility with all major 
> > ARM debuggers and another version of the JTAGjet supports ETM.
> 
> ...your point?
> 

Relevancy and fair representation.

If your product is used it will only work with your ARM IDE 
(including debugger). Signum claim the JTAGjet will work with all 
major ARM debugger and compilers such as IAR, GNU, ARM etc. Signum 
does not list your product as a major ARM product.

ETM (Embedded Trace Macrocell) is fitted to all the LPC2xxx products 
and so it is relevant for debugging. It does not use the JTAG ports

Some additional relevant points

Since JTAG is bi-directional, faster downloads mean fast uploads. 
Fast uploads mean fast filling of data blocks at breakpoints, which 
is the point Chris mentioned.  Developers examine breakpoints more 
often than they download.

Keeping code in RAM means more breakpoints become enabled than the 
two breakpoints that are available when debugging code in Flash 
(unless fancy tricks are used that reduces flash life).

Even if all code will not fit in RAM, some of the code can be copied 
from flash to RAM during startup to run from RAM. The code running 
from RAM will also have the luxury of not being limited to two 
breakpoints.

I really don't have time for this. It does not earn me bread and 
butter. I am not a ARM or any other tools vendor or representative.

I have evaluated an LPC2xxxx part using a Wiggler clone with OCD 
Remote/Insight. I am working on projects with another non ARM part 
that uses a USB debugger. I know the value of being able to read back 
data quickly into a debugger at breakpoints and I know the value of 
being able to obtain trace information unobtrusively. I monitor the 
group to keep abreast of interesting developments that I may use in 
the future. I do not enjoy participating in negative debate.

John Heenan

Re: Slow OCD Remote/Insight debugging

2005-10-06 by John Heenan

With regard to improving JTAG clocking speed, I should rephrase as I 
acknowledge ARM newsgroups have higher ratios of educated and informed 
participants.

Simple techniques such as avoiding lengthy PCB tracks, using 
appropriate cabling and using termination resistors may be all that is 
needed to get dramatic improvements in JTAG clocking speed.

I am sorry if this unleashes the 'holier-than-thous' among us waiting 
for an excuse to assert their 'heroic insights'.

John Heenan

--- In lpc2000@yahoogroups.com, "John Heenan" <l10@a...> wrote:
Show quoted textHide quoted text
> 
> I am not an expert on the limiting issues of maximum JTAG TCK 
> clocking speeds, however I suspect if there are such issues it is has 
> to do with factors independent of the part, which may be simply 
> solved. For example using proper speed cabling and including simple 
> RC filters to reduce signal crossover at high speeds near part pins.
>

RE: [lpc2000] Re: Slow OCD Remote/Insight debugging

2005-10-06 by Paul Curtis

John, 

> > > The Signum JTAGjet claims download speed in excess of 1 
> MByte/sec, 
> > > not 1Mbit/sec.
> > 
> > You can't get anywhere near that on ARM7TDMI-S parts which we are 
> > dicussing,
> 
> Comments below!
> 
> > so this claimed speed is irrelevant in this instance.
> 
> You made a factual error about the hardware capibility of 
> another product in the course of sneering the product. You 
> stated words to the effect "Not so jet after all".

No, I don't think I made that assumption.  I didn't sneer either--I just
said in this instance we've proven that the expensive JTAGjet is slower
than a $20 wiggler when downloading and flashing an LPC229x.  I've even
provided numbers to prove it.

> First ETM (Embedded Trace Macrocell) is fitted to all 
> LPC2xxxx ARM7TDMI-S parts and uses pins independently of JTAG 
> and so TCK. If LPC2xxxx parts are happy to support ETM 
> speeds, I don't see why the same parts cannot support very 
> high JTAG speeds. Why should one set of pins support very 
> high speeds and not another.

Try this link.  http://www.arm.com/support/faqip/3732.html.  Extracting
the relevent details, "If the RTCK output is not used, it is required
that TCK is running at a maximum of 1/6th the system clock frequency if
only 1 JTAG synchroniser is implemented in the system."  Although the
ETM will run quickly as it's driven from the core, JTAG will not run
quickly because without RTCK you can't send data at more than 1/6th the
system clock frequency.  For an LPC2k at 10MHz, that's 1.67MHz TCK.

> Second the JTAG hardware embedded in ARM7TDMI-S parts is not 
> part of the core hardware. It monitors the buses and bus 
> signals and is clocked independently of the core with the JTAG TCK.

Correct.

> Third the core hardware is hard hardware. Whether the ARM 
> core is labelled with S or not for synthesised has nothing to 
> do with the speed at which the independent JTAG hardware can 
> be clocked at. While I acknowledge non synthesised designed 
> cores have less risk attached to them in terms of using 
> proven hardware designs, there is no inherent reason why 
> synthesised cores cannot have their JTAGS clocked at well over 1Mhz.

Read the above.  I didn't say they could not.  I can achieve a 4MHz TCLK
on an ARM7TDMI-S.

> I am not an expert on the limiting issues of maximum JTAG TCK 
> clocking speeds, however I suspect if there are such issues 
> it is has to do with factors independent of the part, which 
> may be simply solved. For example using proper speed cabling 
> and including simple RC filters to reduce signal crossover at 
> high speeds near part pins.

No, you're completely wrong here.  The factors are part of the JTAG
design on the part, as the above link shows.

> > > From the Signum web site
> > > http://www.signum.com/Signum.htm "Actual speed 1.062 Mbyte/sec 
> > > tested with ARM Evaluator 7T board and 600 MHz Pentium 
> III PC with 
> > > USB 2.0 port. Faster PCs may yield faster downloads."
> > 
> > Yes, the Evaluator-7T is a hard core and TCK can be clocked at
> 10MHz in
> > this case (or greater in some cases).  However, not all ARM parts 
> > support this.
> 
> Hard core or not is not relevant. See above.

Yes, it certainly *is* relevant.  The ARM7TDMI is different from an
ARM7TDMI-S and the internal JTAG architecture *is* different.  ARM even
produce a document showing the differences.

> > > Since the JTAGjet uses USB 2.0 this is reasonable, provivded the 
> > > target device and connections can hold up.
> > 
> > USB 2.0 conformance does not imply a high speed device.  
> CrossConnect is
> > a USB 2.0 full speed device. Is the JTAGjet a full speed or high
> speed
> > device?  Or are you making the assumption that all USB 2.0 devices
> are
> > high speed and equating 2.0 devices to be inherently faster 
> than 1.1 
> > devices?  USB 1.1 full speed devices can support 1Mbyte/sec data
> rates
> > over USB so the statement "Since the JTAGjet uses USB 2.0 this is 
> > reasonable" holds no weight.
> 
> What are you trying to pull off here?  Of course it holds weight. 
> Since the specs mention capibility up to 480Mbits per second 
> then we can assume the JTAGjet advertises itself to the USB 
> bus as being able to support full USB 2.0 speed and not only 
> that, appears to claim capibility of processing the USB speed 
> offered from and to the without signalling bottlenecks, if 
> the part allows. Since I don't have the USB specs to hand I 
> do not know what the highest average speed that USB 2.0 is 
> capable of supporting from the PC side.

A USB 2.0 device can run at 12 or 480Mbps.  If you say "full USB 2.0
speed" then that means 12Mbps.  Even so, a full speed device should be
able to transfer data at well over 1MB/second, which is 8Mbps.

> > > The Signum JTAGjet also claims compatibility with all major ARM 
> > > debuggers and another version of the JTAGjet supports ETM.
> > 
> > ...your point?
> > 
> 
> Relevancy and fair representation.
> 
> If your product is used it will only work with your ARM IDE 
> (including debugger).

For now, yes.

> Signum claim the JTAGjet will work with 
> all major ARM debugger and compilers such as IAR, GNU, ARM 
> etc. Signum does not list your product as a major ARM product.

I wouldn't want it to.  We are not in the Signum market.

> ETM (Embedded Trace Macrocell) is fitted to all the LPC2xxx 
> products and so it is relevant for debugging. It does not use 
> the JTAG ports

Pardon?  The ETM connector does use JTAG signals and they are require
for debugging.  The ETM is for tracing.

> Some additional relevant points
> 
> Since JTAG is bi-directional, faster downloads mean fast uploads. 
> Fast uploads mean fast filling of data blocks at breakpoints, 
> which is the point Chris mentioned.  Developers examine 
> breakpoints more often than they download.

What does "examining a breakpoint" mean?  How much data do you need to
upload at a breakpoint for heaven's sake?

> Keeping code in RAM means more breakpoints become enabled 
> than the two breakpoints that are available when debugging 
> code in Flash (unless fancy tricks are used that reduces flash life).

I agree here.

> Even if all code will not fit in RAM, some of the code can be 
> copied from flash to RAM during startup to run from RAM. The 
> code running from RAM will also have the luxury of not being 
> limited to two breakpoints.

Correct.

> I really don't have time for this.

Sure you do.  Otherwise you wouldn't have responded.

-- Paul

Re: [lpc2000] Re: Slow OCD Remote/Insight debugging

2005-10-06 by Charles Manning

On Thursday 06 October 2005 15:38, John Heenan wrote:
> Second the JTAG hardware embedded in ARM7TDMI-S parts is not part of
> the core hardware. It monitors the buses and bus signals and is
> clocked independently of the core with the JTAG TCK.
>
> Third the core hardware is hard hardware. Whether the ARM core is
> labelled with S or not for synthesised has nothing to do with the
> speed at which the independent JTAG hardware can be clocked at. While
> I acknowledge non synthesised designed cores have less risk attached
> to them in terms of using proven hardware designs, there is no
> inherent reason why synthesised cores cannot have their JTAGS clocked
> at well over 1Mhz.

This is not actually true. The ICEBreaker is part of the core.

Non-S parts have independent clocking for the ICEBreaker and the JTAG speed is 
basically as fast as the JTAG/ICEBreaker circuit on the chip will handle (ie 
limited by transmission effects, slew rates etc).

S parts use the MCLK to deglitch the JTAG lines. The maximum speed is 1/6 the 
MCLK speed.

This is clearly documented in one of the docs on www.arm.com.

This introduces some interesting quirkiness for devices that start on a slow 
clock and then switch to a faster clock later.


As for the other points being made: My 2c...

The JTAG or USB speeds are not the only important issue when it codes to 
debugging speed. One very important factor is where the core-handling logic 
is. For example, if the JTAGger is just a "dumb" JTAG probe then a lot of low 
level JTAG transactions need to be passed over the USB link to do anything 
useful. If the JTAG probe instead has ARM core smarts built in, then  the 
traffic can be much higher level. eg. "We hit a break and here is the 
register set". The top-end units (bdi200 and friends) implement the whole lot 
in the debugger.

A slow but smart JTAGger will knock the pants off a fast but dumb one any day.

Re: Slow OCD Remote/Insight debugging

2005-10-06 by John Heenan

--- In lpc2000@yahoogroups.com, "Paul Curtis" <plc@r...> wrote:
> John, 
> 
I just
> said in this instance we've proven that the expensive JTAGjet is 
slower
> than a $20 wiggler when downloading and flashing an LPC229x.  I've 
even
> provided numbers to prove it.

You don't seem to be getting the message. We really don't care if one 
device is more optimally used by external software than another for 
downloading to flash. A few seconds here or there every 10 minutes or 
so is not a big issue. Getting information quickly into a debuuger at 
a breakpoint is a big issue.

There is more to the life of developers than downloading to flash and 
there are very important uses for JTAG debuggers when higher speeds 
are a wonderful convenience.

You know a Wiggler or compatible has no buffering capability, is 
clocked under PC software control (via dead simple drivers if W2K or 
XP) and is at the mercy of the operating system and PC hardware.

> 
> > First ETM (Embedded Trace Macrocell) is fitted to all 
> > LPC2xxxx ARM7TDMI-S parts and uses pins independently of JTAG 
> > and so TCK. If LPC2xxxx parts are happy to support ETM 
> > speeds, I don't see why the same parts cannot support very 
> > high JTAG speeds. Why should one set of pins support very 
> > high speeds and not another.
> 
> Try this link.  http://www.arm.com/support/faqip/3732.html.  
Extracting
> the relevent details, "If the RTCK output is not used, it is 
required
> that TCK is running at a maximum of 1/6th the system clock 
frequency if

Suppose RTCK is used then the limitation does not apply.

Suppose the system clock frequency is 60Mhz. Then TCK maximum is 
10Mhz if RTCK output is not taken advantage of. 


> only 1 JTAG synchroniser is implemented in the system."  Although 
the
> ETM will run quickly as it's driven from the core, JTAG will not run
> quickly because without RTCK you can't send data at more than 1/6th 
the
> system clock frequency.  For an LPC2k at 10MHz, that's 1.67MHz TCK.

See above why this is irrelevant to this posting. LPC2xxx parts are 
rated up to 60Mhz and have buffering techniques to minimise wait 
states when executing from flash.

> 
> > I am not an expert on the limiting issues of maximum JTAG TCK 
> > clocking speeds, however I suspect if there are such issues 
> > it is has to do with factors independent of the part, which 
> > may be simply solved. 
> 
> No, you're completely wrong here.  The factors are part of the JTAG
> design on the part, as the above link shows.

No you are wrong. Clearly explained above

 
> Pardon?  The ETM connector does use JTAG signals and they are 
require
> for debugging.  The ETM is for tracing.

ETM pins ON PARTS are not shared with JTAG pins ON PARTS. A single 
Mictor connector may include connections to both set of pins

Tracing is used as a debugging tool.

> > I really don't have time for this.
> 
> Sure you do.  Otherwise you wouldn't have responded.

No I don't have time for this. It brings no benefit to those 
supporting my projects and is not productive. While I recognise those 
who partake in debates can gain noteriety, that is not my business. 


John Heenan

Re: Slow OCD Remote/Insight debugging

2005-10-06 by John Heenan

--- In lpc2000@yahoogroups.com, Charles Manning <manningc2@a...> 
wrote:
> Non-S parts have independent clocking for the ICEBreaker and the 
JTAG speed is 
> basically as fast as the JTAG/ICEBreaker circuit on the chip will 
handle (ie 
> limited by transmission effects, slew rates etc).
> 
> S parts use the MCLK to deglitch the JTAG lines. The maximum speed 
is 1/6 the 
> MCLK speed.
> 

Thanks for your comments. However the above limitation only applies 
if RTCK is not used.

This is from http://www.arm.com/support/faqip/3732.html

"It is possible to avoid using the RTCK signal shown in the diagram, 
however if the RTCK output is not used, it is required that TCK is 
running at a maximum of 1/6th the system clock frequency if only 1 
JTAG synchroniser is implemented in the system"

Apart from this if takes good board design and connectivity to take 
advantage of the JTAG TCK beyond 1Mhz.

Since we are at this advanced level it may be of interest to point 
out to readers how JTAG uses its bus monitoring to get instructions 
executed and information in and out of memory.

JTAG uses very simple but messy techniques. There is open source 
software that clearly demonstrates these techniques.

JTAG not only read buses it can write to them when the core is under 
debug control. JTAG can pipe a limited range of instructions into the 
JTAG core for execution under JTAG debug control or under subsequent 
temporary non debug system control (a signal is set that places the 
core straight back into debug control).  Since reading and writing to 
memory needs to be carried out at system speed, JTAG pipes in a 
single read to registers or write from registers to execute at system 
speed. 

For writing instructions are piped in prior that load the registers 
with values to write

For reading instcutions are piped in afterwards to make the values 
read into the registers appear on the bus for monitoring.

Very simple, very effective and very messy.

John Heenan


> This is clearly documented in one of the docs on www.arm.com.
> 
> This introduces some interesting quirkiness for devices that start 
on a slow 
> clock and then switch to a faster clock later.
> 
> 
> As for the other points being made: My 2c...
> 
> The JTAG or USB speeds are not the only important issue when it 
codes to 
> debugging speed. One very important factor is where the core-
handling logic 
> is. For example, if the JTAGger is just a "dumb" JTAG probe then a 
lot of low 
> level JTAG transactions need to be passed over the USB link to do 
anything 
> useful. If the JTAG probe instead has ARM core smarts built in, 
then  the 
> traffic can be much higher level. eg. "We hit a break and here is 
the 
> register set". The top-end units (bdi200 and friends) implement the 
whole lot 
> in the debugger.
> 
> A slow but smart JTAGger will knock the pants off a fast but dumb 
one any day.

Re: Slow OCD Remote/Insight debugging

2005-10-07 by John Heenan

The 'max TCK=1/6 MCLK if RTCK not used' rule only appears to apply if 
the core is not in a debug state.

If the core is placed in a debug state, such as at a breakpoint,
there is no system clock to syncronise with!

While in a debug state JTAG will need to execute some one-at-a-time 
piped instructions at system speed before returning straight into a 
debug state (explained in prior posting). This may be an issue if
JTAG is polling for a return to debug state. However there is a hell 
a lot work carried out by JTAG debuggers outside this.

John Heenan




--- In lpc2000@yahoogroups.com, "John Heenan" <l10@a...> wrote:
Show quoted textHide quoted text
> --- In lpc2000@yahoogroups.com, "Paul Curtis" <plc@r...> wrote:

> > Try this link.  http://www.arm.com/support/faqip/3732.html.  
> Extracting
> > the relevent details, "If the RTCK output is not used, it is 
> required
> > that TCK is running at a maximum of 1/6th the system clock 
> frequency if
> 
> Suppose RTCK is used then the limitation does not apply.
> 
> Suppose the system clock frequency is 60Mhz. Then TCK maximum is 
> 10Mhz if RTCK output is not taken advantage of. 
> 
>

Re: [lpc2000] Re: Slow OCD Remote/Insight debugging

2005-10-07 by Charles Manning

On Friday 07 October 2005 13:45, John Heenan wrote:
> The 'max TCK=1/6 MCLK if RTCK not used' rule only appears to apply if
> the core is not in a debug state.
>
> If the core is placed in a debug state, such as at a breakpoint,
> there is no system clock to syncronise with!

That is probably not true. There is still an MCLK, but it is just not being 
used to currently execute the core, however it is still there. Various 
peripherals etc can still be running off MCLK. Without it SDRAM etc will die. 
All register to RAM transfers are done at full clock speed.

I'd have to read it all up again, but from my understanding, the 1/6 rule is 
used by the deglitching logic on the outside of (ie. JTAG side of) the 
ICEBreaker. There is nothing I have read to suggest that the deglitcher turns 
off during debug, so I assume the clock is still there and used.

As for RTCK, this is academic. A synchronous deglitcher will essentially 
throttle the RTCK speed to 1/6 anyway.

>
> While in a debug state JTAG will need to execute some one-at-a-time
> piped instructions at system speed before returning straight into a
> debug state (explained in prior posting). This may be an issue if
> JTAG is polling for a return to debug state. However there is a hell
> a lot work carried out by JTAG debuggers outside this.

Very much agree and that is why I made the point of dumb vs smart probes,

Consider the case of writing some data into RAM:
Smart probe:
  Host: Write these bytes to address xxx"
  Probe: Done
Dumb probe:
  Host: Read this jtag register
  Probe: Here it is
  Host: Now Write this jtag register
  Host: Now Run-test-idle
  <above sequence for n times>
  Host: Read status
  Probe: Here it is
  <above until the core returns to debug state>

The dumb probe scenario has had to shovel a lot of data through the host's 
drivers and control application. This adds a lot of latency. Smarter probes 
can handle the core interaction with no help from the host and can process 
the data a lot faster.

Even while the core is running, there is a lot of stuff that should be going 
on monitoring the state of the device and servicing the debug communications 
channel (DCC). Very few, if any, of the low end JTAG devices do this properly 
and I have not seen any that support DCC - probably for that reason [I admit 
I have not looked hard]. The "smart" probes will handle all the core state 
(including DCC handling) in the probe. "Dumb" probes that send bit wiggles or 
low-level JTAG commands over the USB cannot do an effective job of handling 
DCC etc.

IMHO a good debugger will spend all its running time reading the debug status. 
It should be able to read this approx 20-100k times per second. That can make 
a DCC that transfers probably around 100kbytes per second.

A "dumb" probe can probably only read the status 1k times per second and can 
probably manage no more than 4 or 5 kbytes per sec over the DCC channel.

Most of the performance in a debugger is linked to its ability to do higher 
level activities autonomously. While the JTAG clock is obviously a factor it 
is far from being the most important factor.

Re: [lpc2000] Re: Slow OCD Remote/Insight debugging

2005-10-07 by sig5534@hotmail.com

> > You can't get anywhere near that on ARM7TDMI-S parts which we are 
> > dicussing,
 
Correct.  The maximum speed I can use with the JTAGjet is 4MHz on these LPC parts.
BTW, I was incorrect before, the JTAGjet goes to 30MHz when I checked it again.

>> said in this instance we've proven that the expensive JTAGjet is slower
>> than a $20 wiggler when downloading and flashing an LPC229x.  I've even
>> provided numbers to prove it.

It is not as simple as you try to make it.  The Signum Chameleon debugger software has a ton of features, and many different options and capabilities.  The price is not so much for the debugger hardware, as it is for the software.  The software is superb.  Best debugger I have ever used by far.  Price I paid was $1200, and when you compare that to Greenhills and others I think it is a good value and much cheaper.  It also supports a ton of CPUs and DSPs.

Programming can be done in different ways, and each has different advantages and disadvantages.  One method may take longer than another, but the way in which Signum handles this provides great flexibility and control.

>> Try this link.  http://www.arm.com/support/faqip/3732.html.  Extracting
>> the relevent details, "If the RTCK output is not used, it is required
>> that TCK is running at a maximum of 1/6th the system clock frequency if
>> only 1 JTAG synchroniser is implemented in the system."  

I use both the Adaptive clocking (RTCK) and fixed freq on my JTAGjet.  It does both equally well.

>> For example using proper speed cabling 
>> and including simple RC filters to reduce signal crossover at 
>> high speeds near part pins.
> No, you're completely wrong here.  The factors are part of the JTAG
> design on the part, as the above link shows.

Correct.  I have actually tried attaching caps on the JTAG header pins and nothing I did made any difference on the 4MHz speed limitation.

> > USB 2.0 conformance does not imply a high speed device.  CrossConnect is
> > a USB 2.0 full speed device. Is the JTAGjet a full speed or high speed device?  

It is Full speed.  The USB-2 terminology has become misused, and if you look at the USB.ORG web site you will see a notice that they actually do not want people saying "USB 2.0" if it is only full speed.  Philips makes this same exageration on their own 2148 series parts which say "USB 2.0" but they are Full speed.

>> What does "examining a breakpoint" mean?  
>> How much data do you need to upload at a breakpoint for heaven's sake?

A ton.  I have watches on large structures where I need to read 8K blocks of data, and that data must be read whenever I stop the CPU.  There is a lot of data flow, but then Chameleon processes a lot of data.  In some cases I also need to download corrected blocks to RAM.  It's just a whole lot snappier with the JTAGjet than a wiggler.  At least that's what I see.

Chris.



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

Re: Slow OCD Remote/Insight debugging

2005-10-07 by John Heenan

--- In lpc2000@yahoogroups.com, Charles Manning <manningc2@a...> 
wrote:
>
> On Friday 07 October 2005 13:45, John Heenan wrote:
> > The 'max TCK=1/6 MCLK if RTCK not used' rule only appears to 
apply if
> > the core is not in a debug state.
> >
> > If the core is placed in a debug state, such as at a breakpoint,
> > there is no system clock to syncronise with!
> 
> That is probably not true. There is still an MCLK, but it is just 
not being 
> used to currently execute the core, however it is still there. 

Thanks for your follow up.

In a debug state there is no system clock activity relevant to JTAG.

The point I was making below is that apart from when JTAG must allow 
some instructions to execute at system speed, the rule does not 
appear to have relevance. Of course there may be other limiting 
factors, but hardly the synchronising one since there is nothing to 
synchronise with.

John Heenan

Various 
> peripherals etc can still be running off MCLK. Without it SDRAM etc 
will die. 
> All register to RAM transfers are done at full clock speed.
> 

> I'd have to read it all up again, but from my understanding, the 
1/6 rule is 
> used by the deglitching logic on the outside of (ie. JTAG side of) 
the 
> ICEBreaker. There is nothing I have read to suggest that the 
deglitcher turns 
> off during debug, so I assume the clock is still there and used.
> 
> As for RTCK, this is academic. A synchronous deglitcher will 
essentially 
> throttle the RTCK speed to 1/6 anyway.
> 
> >
> > While in a debug state JTAG will need to execute some one-at-a-
time
> > piped instructions at system speed before returning straight into 
a
> > debug state (explained in prior posting). This may be an issue if
> > JTAG is polling for a return to debug state. However there is a 
hell
> > a lot work carried out by JTAG debuggers outside this.
> 
> Very much agree and that is why I made the point of dumb vs smart 
probes,
> 
> Consider the case of writing some data into RAM:
> Smart probe:
>   Host: Write these bytes to address xxx"
>   Probe: Done
> Dumb probe:
>   Host: Read this jtag register
>   Probe: Here it is
>   Host: Now Write this jtag register
>   Host: Now Run-test-idle
>   <above sequence for n times>
>   Host: Read status
>   Probe: Here it is
>   <above until the core returns to debug state>
> 
> The dumb probe scenario has had to shovel a lot of data through the 
host's 
> drivers and control application. This adds a lot of latency. 
Smarter probes 
> can handle the core interaction with no help from the host and can 
process 
> the data a lot faster.
> 
> Even while the core is running, there is a lot of stuff that should 
be going 
> on monitoring the state of the device and servicing the debug 
communications 
> channel (DCC). Very few, if any, of the low end JTAG devices do 
this properly 
> and I have not seen any that support DCC - probably for that reason 
[I admit 
> I have not looked hard]. The "smart" probes will handle all the 
core state 
> (including DCC handling) in the probe. "Dumb" probes that send bit 
wiggles or 
> low-level JTAG commands over the USB cannot do an effective job of 
handling 
> DCC etc.
> 
> IMHO a good debugger will spend all its running time reading the 
debug status. 
> It should be able to read this approx 20-100k times per second. 
That can make 
> a DCC that transfers probably around 100kbytes per second.
> 
> A "dumb" probe can probably only read the status 1k times per 
second and can 
> probably manage no more than 4 or 5 kbytes per sec over the DCC 
channel.
> 
> Most of the performance in a debugger is linked to its ability to 
do higher 
> level activities autonomously. While the JTAG clock is obviously a 
factor it 
> is far from being the most important factor.
>

Re: Slow OCD Remote/Insight debugging

2005-10-07 by John Heenan

--- In lpc2000@yahoogroups.com, <sig5534@h...> wrote:
>
> > > You can't get anywhere near that on ARM7TDMI-S parts which we 
are 
> > > dicussing,
>  
> Correct.  The maximum speed I can use with the JTAGjet is 4MHz on 
these LPC parts.
> BTW, I was incorrect before, the JTAGjet goes to 30MHz when I 
checked it again.

There has been no information provivded or pointed to that puts the 
limiting factor on the ARM7TDMI-S part itself. 

Adaptive RTCK use overcomes the 1/6 rule when the core is not in a 
debug state. In a debug state there is no clock relevant to JTAG to 
synchronise to.  Yes I am aware of the 'switch to system speed and 
back to debug' issue.

There are lots of reasons why speed becomes maxed out. Not the least 
of which is wiring. 

It would be nice to know what the limiting factor is to investigate 
if it can be overcome and so use the more capable debug tools to 
their full capacity. 

John Heenan

> >> Try this link.  http://www.arm.com/support/faqip/3732.html.  
Extracting
> >> the relevent details, "If the RTCK output is not used, it is 
required
> >> that TCK is running at a maximum of 1/6th the system clock 
frequency if
> >> only 1 JTAG synchroniser is implemented in the system."  
> 
> I use both the Adaptive clocking (RTCK) and fixed freq on my 
JTAGjet.  It does both equally well.
> 
> >> For example using proper speed cabling 
> >> and including simple RC filters to reduce signal crossover at 
> >> high speeds near part pins.
> > No, you're completely wrong here.  The factors are part of the 
JTAG
> > design on the part, as the above link shows.
> 
> Correct.  I have actually tried attaching caps on the JTAG header 
pins and nothing I did made any difference on the 4MHz speed 
limitation.

I am sorry but I don't regard this as conclusive.

John Heenan

Re: Slow OCD Remote/Insight debugging. Hard information from logic diagrams

2005-10-08 by John Heenan

I have closely examined JTAG synchronisation logic diagrams for 
synthesized cores on the official ARM web site

Reading logic diagrams is a skill I first learnt at university in 
Ireland in the seventies from an enthusiastic and fresh lecturer from 
England whose career was sadly cut short following his death in a car 
accident in France.

The synchronisation logic ENFORCES the following.
1. An enforcement of maximum possible TCK frequency of 1/6 of the 
internal clock frequency.
2. An enforcement that internal clock must be applied to the logic 
when the core is in a debug state and the core is not been clocked 
itself. 
3. An enforcement that RTCK, which can be used to trigger CLK, is a 
maximum possible of 1/6 the internal clock

So I acknowledge
1. Use of RTCK cannot raise throughput during the non debug state
2. During debug state the 1/6 rule applies 

However I will not acknowledge that the entire set of enforcements is 
strictly necessary. 

So far I have not been able to find out why ARM insists on 
enforcement of the 1/6 rule for synthesized cored. My guess is that 
the rules are grossly conservative and not due for any inherent 
property of synthesized cores as opposed to 'hard' cores.

I have included some quotes from ARM from links below. I have doubts 
whether the quotes make complete sense given the enforcement nature 
of the logic. However I have no wish to spend time debating this.

Also the enforcement nature of the logic lends supports that problems 
reaching 1/6 MCLK are due to problems external to the part, such 
using cabling and termination that is inappropriate for the speed.

Informative links are 
http://www.arm.com/support/faqdev/4170.html
(How does the JTAG synchronisation logic work? / How does adaptive 
clocking work?)

and

http://www.arm.com/support/faqdev/1321.html
(What is the maximum TCK frequency that I can set up with Multi-ICE?)

The Multi-ICE debugger is the 'official' JTAG debugger of ARM. The 
information is relevant to other debuggers.

Multi-ICE can generate a maximum TCK frequency of 10MHz

For hard macrocells ARM states:
"You should normally be able to work with TCK faster than 1MHz".

For synthesizable cores ARM states:
"The three sampling flip-flops set the theoretical maximum TCK 
frequency, which is one sixth of the core clock frequency (one eighth 
in ARM11)..." 
and 
"The real maximum TCK frequency will be lower than this and will 
depend on the core clock frequency, the delays on the JTAG signals 
and the setup time of Multi-ICE and the ASIC."

Also
"If your target provides RTCK, you can also configure Multi-ICE in 
adaptive clocking mode. Multi-ICE will automatically work at a TCK 
frequency close to the maximum possible one."


John Heenan


--- In lpc2000@yahoogroups.com, "John Heenan" <l10@a...> wrote:
>
> --- In lpc2000@yahoogroups.com, <sig5534@h...> wrote:
> >
> > > > You can't get anywhere near that on ARM7TDMI-S parts which we 
> are 
> > > > dicussing,
> >  
> > Correct.  The maximum speed I can use with the JTAGjet is 4MHz on 
> these LPC parts.
> > BTW, I was incorrect before, the JTAGjet goes to 30MHz when I 
> checked it again.
> 
> There has been no information provivded or pointed to that puts the 
> limiting factor on the ARM7TDMI-S part itself. 
> 
> Adaptive RTCK use overcomes the 1/6 rule when the core is not in a 
> debug state. In a debug state there is no clock relevant to JTAG to 
> synchronise to.  Yes I am aware of the 'switch to system speed and 
> back to debug' issue.
> 
> There are lots of reasons why speed becomes maxed out. Not the 
least 
Show quoted textHide quoted text
> of which is wiring. 
> 
> It would be nice to know what the limiting factor is to investigate 
> if it can be overcome and so use the more capable debug tools to 
> their full capacity. 
> 
> John Heenan
> 
> > >> Try this link.  http://www.arm.com/support/faqip/3732.html.  
> Extracting
> > >> the relevent details, "If the RTCK output is not used, it is 
> required
> > >> that TCK is running at a maximum of 1/6th the system clock 
> frequency if
> > >> only 1 JTAG synchroniser is implemented in the system."  
> > 
> > I use both the Adaptive clocking (RTCK) and fixed freq on my 
> JTAGjet.  It does both equally well.
> > 
> > >> For example using proper speed cabling 
> > >> and including simple RC filters to reduce signal crossover at 
> > >> high speeds near part pins.
> > > No, you're completely wrong here.  The factors are part of the 
> JTAG
> > > design on the part, as the above link shows.
> > 
> > Correct.  I have actually tried attaching caps on the JTAG header 
> pins and nothing I did made any difference on the 4MHz speed 
> limitation.
> 
> I am sorry but I don't regard this as conclusive.
> 
> John Heenan
>

Re: [lpc2000] Re: Slow OCD Remote/Insight debugging. Hard information from logic diagrams

2005-10-08 by Rob Jansen

John Heenan writes:

>  So I acknowledge
>  1. Use of RTCK cannot raise throughput during the non debug state
>  2. During debug state the 1/6 rule applies
>
>  However I will not acknowledge that the entire set of enforcements is
>  strictly necessary.

Agree, but I am not sure how the DBGTCKEN is used by the EmbeddedICE module.
If what I think is true you would be able to clock in data at a higher
speed (up to CLK?) after having your first positive edge on RTCK. This may
- or may not - work and I'm not in the mood for trying this out myself.

I'm currently using an lpc21xx to control the JTAG of the next one using
software. If you start using a TCK > 1/6 CLK (if possible at all ...) then
you need to take care of RTCK synchronization in a completely different
way.

>  Informative links are

Thanks, I had not seen the timing diagrams (they were not in my pdf file)
but I have figured things out from the schematics. My software is also
using the adaptive clocking mode as described in software:

    - set TMS & TDI to correct values
    - raise TCK
    - wait for RTCK
    - drop TCK

And then wait for RTCK to be low before the next bit to write.

This works, I am able to talk to the EmbeddedICE registers without any
problem. Communication with the Debug Communication Channel (DCC) is also
no problem.

I am now reading that part of the spec where it tells me how to clock the
instructions into the chain. It's all about reading the documentation
carefully ...

Rob

Re: Slow OCD Remote/Insight debugging. Hard information from logic diagrams

2005-10-08 by John Heenan

I should explain what I mean by enforcement logic.

What the synchronization logic really does is deliberately distort 
your triggering UNLESS you stick to the 1/6 rule.

It is like a policeman that says we don't care if you break the speed 
limit and if the speed limit is too low, as we have speed detectors 
that will trigger lasers to destroy your car if you go over the 
limit.

The combination of three edge triggered D flip-flops with a logic 
gate that requires the input to the final flip-flop to be different 
to what was latched on the prior triggering clock edge to the same 
flip-flop means that you must stick to the 1/6 rule to ensure the 
output from the logic reflects the TCK input.

John Heenan


--- In lpc2000@yahoogroups.com, "John Heenan" <l10@a...> wrote:
>
> I have closely examined JTAG synchronisation logic diagrams for 
> synthesized cores on the official ARM web site
> 
> Reading logic diagrams is a skill I first learnt at university in 
> Ireland in the seventies from an enthusiastic and fresh lecturer 
from 
> England whose career was sadly cut short following his death in a 
car 
> accident in France.
> 
> The synchronisation logic ENFORCES the following.
> 1. An enforcement of maximum possible TCK frequency of 1/6 of the 
> internal clock frequency.
> 2. An enforcement that internal clock must be applied to the logic 
> when the core is in a debug state and the core is not been clocked 
> itself. 
> 3. An enforcement that RTCK, which can be used to trigger CLK, is a 
> maximum possible of 1/6 the internal clock
> 
> So I acknowledge
> 1. Use of RTCK cannot raise throughput during the non debug state
> 2. During debug state the 1/6 rule applies 
> 
> However I will not acknowledge that the entire set of enforcements 
is 
> strictly necessary. 
> 
> So far I have not been able to find out why ARM insists on 
> enforcement of the 1/6 rule for synthesized cored. My guess is that 
> the rules are grossly conservative and not due for any inherent 
> property of synthesized cores as opposed to 'hard' cores.
> 
> I have included some quotes from ARM from links below. I have 
doubts 
> whether the quotes make complete sense given the enforcement nature 
> of the logic. However I have no wish to spend time debating this.
> 
> Also the enforcement nature of the logic lends supports that 
problems 
> reaching 1/6 MCLK are due to problems external to the part, such 
> using cabling and termination that is inappropriate for the speed.
> 
> Informative links are 
> http://www.arm.com/support/faqdev/4170.html
> (How does the JTAG synchronisation logic work? / How does adaptive 
> clocking work?)
> 
> and
> 
> http://www.arm.com/support/faqdev/1321.html
> (What is the maximum TCK frequency that I can set up with Multi-
ICE?)
> 
> The Multi-ICE debugger is the 'official' JTAG debugger of ARM. The 
> information is relevant to other debuggers.
> 
> Multi-ICE can generate a maximum TCK frequency of 10MHz
> 
> For hard macrocells ARM states:
> "You should normally be able to work with TCK faster than 1MHz".
> 
> For synthesizable cores ARM states:
> "The three sampling flip-flops set the theoretical maximum TCK 
> frequency, which is one sixth of the core clock frequency (one 
eighth 
> in ARM11)..." 
> and 
> "The real maximum TCK frequency will be lower than this and will 
> depend on the core clock frequency, the delays on the JTAG signals 
> and the setup time of Multi-ICE and the ASIC."
> 
> Also
> "If your target provides RTCK, you can also configure Multi-ICE in 
> adaptive clocking mode. Multi-ICE will automatically work at a TCK 
> frequency close to the maximum possible one."
> 
> 
> John Heenan
> 
> 
> --- In lpc2000@yahoogroups.com, "John Heenan" <l10@a...> wrote:
> >
> > --- In lpc2000@yahoogroups.com, <sig5534@h...> wrote:
> > >
> > > > > You can't get anywhere near that on ARM7TDMI-S parts which 
we 
> > are 
> > > > > dicussing,
> > >  
> > > Correct.  The maximum speed I can use with the JTAGjet is 4MHz 
on 
> > these LPC parts.
> > > BTW, I was incorrect before, the JTAGjet goes to 30MHz when I 
> > checked it again.
> > 
> > There has been no information provivded or pointed to that puts 
the 
> > limiting factor on the ARM7TDMI-S part itself. 
> > 
> > Adaptive RTCK use overcomes the 1/6 rule when the core is not in 
a 
> > debug state. In a debug state there is no clock relevant to JTAG 
to 
> > synchronise to.  Yes I am aware of the 'switch to system speed 
and 
> > back to debug' issue.
> > 
> > There are lots of reasons why speed becomes maxed out. Not the 
> least 
> > of which is wiring. 
> > 
> > It would be nice to know what the limiting factor is to 
investigate 
> > if it can be overcome and so use the more capable debug tools to 
> > their full capacity. 
> > 
> > John Heenan
> > 
> > > >> Try this link.  http://www.arm.com/support/faqip/3732.html.  
> > Extracting
> > > >> the relevent details, "If the RTCK output is not used, it is 
> > required
> > > >> that TCK is running at a maximum of 1/6th the system clock 
> > frequency if
> > > >> only 1 JTAG synchroniser is implemented in the system."  
> > > 
> > > I use both the Adaptive clocking (RTCK) and fixed freq on my 
> > JTAGjet.  It does both equally well.
> > > 
> > > >> For example using proper speed cabling 
> > > >> and including simple RC filters to reduce signal crossover 
at 
> > > >> high speeds near part pins.
> > > > No, you're completely wrong here.  The factors are part of 
the 
> > JTAG
> > > > design on the part, as the above link shows.
> > > 
> > > Correct.  I have actually tried attaching caps on the JTAG 
header 
Show quoted textHide quoted text
> > pins and nothing I did made any difference on the 4MHz speed 
> > limitation.
> > 
> > I am sorry but I don't regard this as conclusive.
> > 
> > John Heenan
> >
>

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.