Jtag clocks

Started by linnix February 20, 2007
On Feb 21, 3:16 am, "Sean Houlihane" <tshoulih...@hotmail.com> wrote:
> >> 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.
It make sense for writing flash, but not for reading/writing sram.
> Slowing down > the JTAG clock does get round this, but it makes for a very slow interface.
Yes, down to several K bytes per second just reading sram.
> > 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.
Agree, 256 cycles is ridiculous.
> > Sean
On Feb 20, 8:16 am, "linnix" <m...@linnix.info-for.us> 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.
Let me leak (/give) out some more info. The customer usually buys batch of identical machines to simplify maintenance. They have three generations of them: Gen A: 200MHz/64M/Win95 Gen B: 1GHz/512M/Win98 Gen C: 2GHz/1G/XP They are primary on Gen B and no great reason to upgrade yet. Old machines never dies, they just inventory away. There is a roomful of Gen A machines in storage, and they are so happy that we can make use of them. Now come the hard part, they need to hookup large number of digital and analog I/Os. So, we come up with USB ARM i/o modules. We use Keil for initial development on Gen C machines, but they are reserved for serious gamers (/power users). Since Win98 won't work on the USB FTDI 2232 and Win2000 won't work with the AGP graphic chip (except 16 colors SVGA), we installed Win2000 on one Gen B machine just for downloading. The USB module is then moved to the Gen A target running Linux. So the cycle is development on Win98, downloading on Win2000 and running on Linux. Now, we are trying very hard to get rid of the Win2000. The downloading is using openocd (usb jtag) on Linux. With a WinOCD client, we can remotely upload/download registers/sram/flash from/to the target machines. It currently takes about 4 seconds to remotely flash 10K to the target, roughly the same time as Keil. However, it doesn't make sure to be so slow for register/sram as well. It's no big deal, but we like to solve the problem. OK, any suggestions.
linnix <me@linnix.info-for.us> wrote:
> It make sense for writing flash, but not for reading/writing sram.
Internally the commands performed by JTAG on the M3 are going through a layer of debug bus fabric, the JTAG is not controlling a TAP controller on the core. Infact depending on how the buses are bridged it may be able to write directly into RAM. I do not know what the design of the Luminary part is though. It therefore does make sense that you have to wait for commands to complete when reading/writing SRAM. In previous debug architectures access to any kind of RAM was accomplished by scanning data into core registers and scanning LDM/STM instructions into the core then executing them. -p -- "Unix is user friendly, it's just picky about who its friends are." - Anonymous --------------------------------------------------------------------