EmbeddedRelated.com
Forums
The 2024 Embedded Online Conference

Jtag clocks

Started by linnix February 20, 2007
I am having problem jtag an ARM Cortex M3 at more than 1/256 of the
system clock (6Mz).  If I clock it any faster, the chip reports data
overrun error.  Is there any solution to speed it up?  I can jtag an
AVR at full speed, so I don't think it's a jtag problem.

linnix wrote:

> I am having problem jtag an ARM Cortex M3 at more than 1/256 of the > system clock (6Mz). If I clock it any faster, the chip reports data > overrun error. Is there any solution to speed it up? I can jtag an > AVR at full speed, so I don't think it's a jtag problem.
That's a strange last sentence. I think you meant jtag-link problem ? Sounds simple to me, if the chip complains when you go faster, then that's their inherent silicon limit, so go slower :) Sounds like some (rom?) debug firmware is being invoked. -jg
On Feb 20, 11:05 am, Jim Granville <no.s...@designtools.maps.co.nz>
wrote:
> linnix wrote: > > I am having problem jtag an ARM Cortex M3 at more than 1/256 of the > > system clock (6Mz). If I clock it any faster, the chip reports data > > overrun error. Is there any solution to speed it up? I can jtag an > > AVR at full speed, so I don't think it's a jtag problem. > > That's a strange last sentence. I think you meant jtag-link problem ? > Sounds simple to me, if the chip complains when you go faster, then > that's their inherent silicon limit, so go slower :) > Sounds like some (rom?) debug firmware is being invoked. > > -jg
Yes, its just reading and writing the core registers. Can't believe that I have to slow it down by 256 cycles for TCK. I can understand it takes many TCK cycles, but the TCK itself is too slow.
"linnix" <me@linnix.info-for.us> wrote in message 
news:1171988201.592918.181770@h3g2000cwc.googlegroups.com...
>I am having problem jtag an ARM Cortex M3 at more than 1/256 of the > system clock (6Mz). If I clock it any faster, the chip reports data > overrun error. Is there any solution to speed it up? I can jtag an > AVR at full speed, so I don't think it's a jtag problem.
What is it you are trying to do? Debug/test/program the device? Which tools are you using? Regards, Richard. + http://www.FreeRTOS.org + http://www.SafeRTOS.com for Cortex-M3, ARM7, ARM9, HCS12, H8S, MSP430 Microblaze, Coldfire, AVR, x86, 8051, PIC24 & dsPIC .... and soon AVR32
On Feb 20, 12:08 pm, "FreeRTOS.org" <noem...@noaddress.com> wrote:
> "linnix" <m...@linnix.info-for.us> wrote in message > > news:1171988201.592918.181770@h3g2000cwc.googlegroups.com... > > >I am having problem jtag an ARM Cortex M3 at more than 1/256 of the > > system clock (6Mz). If I clock it any faster, the chip reports data > > overrun error. Is there any solution to speed it up? I can jtag an > > AVR at full speed, so I don't think it's a jtag problem. > > What is it you are trying to do?
Read/write the registers and memories.
> Debug/test/program the device?
Yes/yes/yes
> Which tools are you using?
openocd
Jim Granville <no.spam@designtools.maps.co.nz> wrote:
> That's a strange last sentence. I think you meant jtag-link problem ? > Sounds simple to me, if the chip complains when you go faster, then > that's their inherent silicon limit, so go slower :) > Sounds like some (rom?) debug firmware is being invoked.
I strongly suspect that the ICE he is using is not using RTCLK to implement adaptive clocking. -p -- "Unix is user friendly, it's just picky about who its friends are." - Anonymous --------------------------------------------------------------------
> >> Which tools are you using? > > openocd >
Hmm. That's probably the only tool I have not tried so cannot offer advice, sorry. CrossWorks/CrossConnect, IAR/J-Link, Keil and CodeSourcery interfaces don't seem to have speed problems. Regards, Richard. + http://www.FreeRTOS.org + http://www.SafeRTOS.com for Cortex-M3, ARM7, ARM9, HCS12, H8S, MSP430 Microblaze, Coldfire, AVR, x86, 8051, PIC24 & dsPIC .... and soon AVR32
On Feb 20, 12:16 pm, Paul Gotch <p...@at-cantab-dot.net> wrote:
> Jim Granville <no.s...@designtools.maps.co.nz> wrote: > > That's a strange last sentence. I think you meant jtag-link problem ? > > Sounds simple to me, if the chip complains when you go faster, then > > that's their inherent silicon limit, so go slower :) > > Sounds like some (rom?) debug firmware is being invoked. > > I strongly suspect that the ICE he is using is not using RTCLK to implement > adaptive clocking.
The jtag clocking is set in the FTDI 2232 chip and the LM3S811 reports data overrun in it's internal logic. I got data overrun for simply reading core registers. So, how can I adaptive clock it? /256 works perfectly, but not /128.
> > -p > -- > "Unix is user friendly, it's just picky about who its friends are." > - Anonymous > --------------------------------------------------------------------
"linnix" <me@linnix.info-for.us> wrote in message
news:1172007010.458775.256330@s48g2000cws.googlegroups.com...
> The jtag clocking is set in the FTDI 2232 chip and the LM3S811 reports > data overrun in it's internal logic. I got data overrun for simply > reading core registers. So, how can I adaptive clock it? /256 works > perfectly, but not /128. >
As far as I know, FTDI2232 does not support RTCK and consequenly does not support adaptive clocking. Slowing down the clock is the only solution :-( - Dejan
>> The jtag clocking is set in the FTDI 2232 chip and the LM3S811 reports >> data overrun in it's internal logic. I got data overrun for simply >> reading core registers. So, how can I adaptive clock it? /256 works >> perfectly, but not /128. >> > As far as I know, FTDI2232 does not support RTCK and consequenly does not > support adaptive clocking. Slowing down the clock is the only solution :-(
SWJ-DP as used in the LM3S811 does not support RTCK, but that does not mean that there is no mechanism for optimising the JTAG transfer speed. The overrun response doesn't indicate that the JTAG speed is too high, it indicates that the gap between the end of one command and the start of the next has not given time for the system to respond internally. Slowing down the JTAG clock does get round this, but it makes for a very slow interface. Try adding some JTAG cycles in Run-Test/Idle after your reads. Even with the JTAG running at the system clock speed, you should only need a few extra cycles here. For writes the minimum response time is probably different. Sean

The 2024 Embedded Online Conference