Jtag clocks

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.

What is it you are trying to do? Debug/test/program the device? Which tools are you using?

Regards, Richard.

• formatting link

• formatting link
  for Cortex-M3, ARM7, ARM9, HCS12, H8S, MSP430 Microblaze, Coldfire, AVR, x86, 8051, PIC24 & dsPIC .... and soon AVR32

Read/write the registers and memories.

Yes/yes/yes

openocd

I strongly suspect that the ICE he is using is not using RTCLK to implement adaptive clocking.

-p

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.

• formatting link

• formatting link
  for Cortex-M3, ARM7, ARM9, HCS12, H8S, MSP430 Microblaze, Coldfire, AVR, x86, 8051, PIC24 & dsPIC .... and soon AVR32

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

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

It make sense for writing flash, but not for reading/writing sram.

Yes, down to several K bytes per second just reading sram.

Agree, 256 cycles is ridiculous.

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.

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