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.
Jtag clocks
Started by ●February 20, 2007
Reply by ●February 20, 20072007-02-20
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
Reply by ●February 20, 20072007-02-20
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. > > -jgYes, 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.
Reply by ●February 20, 20072007-02-20
"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
Reply by ●February 20, 20072007-02-20
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
Reply by ●February 20, 20072007-02-20
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 --------------------------------------------------------------------
Reply by ●February 20, 20072007-02-20
> >> 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
Reply by ●February 20, 20072007-02-20
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 > --------------------------------------------------------------------
Reply by ●February 21, 20072007-02-21
"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
Reply by ●February 21, 20072007-02-21
>> 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
