**** BEGIN LOGGING AT Fri Dec 01 02:59:58 2006 Dec 01 09:27:00 guys, I'm looking for some documentation on how a program on the target can receive data through JTAG. Do you maybe have some links for me? Dec 01 09:28:06 could you specify /the target/ a bit more? Dec 01 09:30:42 well, at this point I don't even understand how JTAG can be used to communicate between host and target (no matter what kinds). I've always thought JTAG has a very limited set of instructions that can do things like write memory. Dec 01 09:31:06 I mean communication between running processes Dec 01 09:31:26 in some way faster than the standard way of accessing memory Dec 01 09:31:38 mhh, okay: Dec 01 09:31:55 jtag specifies a statemachine, a set of registers, and 4 pins that allow serial access to these registers Dec 01 09:32:08 there's an instruction register, that allows you to select one of several instructions Dec 01 09:32:19 depending on the current instruction, a data register is selected Dec 01 09:32:29 the size of these shift-registers is defined by the application Dec 01 09:32:45 JTAG itself further defines boundary-scanning using these shift registers Dec 01 09:33:02 there are up to three bits in the boundary scan register for each device pin Dec 01 09:33:30 the EXTEST instruction for example allows you to read the inputs from the device pins, and drive certain outputs Dec 01 09:33:46 the INTEST instruction does the same, but toward the "inside" of the chip Dec 01 09:34:14 everything beyond that, like accessing memory on a certain microcontroller, isn't part of the JTAG specs Dec 01 09:42:39 so, if I get this correctly, the way to communicate with a running process on the target with standard JTAG is to set some GPIO pins with boundary scan and have the process read them Dec 01 09:43:48 uhm, yeah, but then you'd have to implement everything in software Dec 01 09:45:41 the ARM7 and ARM9 for example has a built-in JTAG interface. It has two major JTAG data registers, one that accesses the data/instruction bus, and one that accesses a few special debug registers (EmbeddedICE) Dec 01 09:45:47 The thing is, I have this JTAG probe working with my MIPS, but it's really slow in downloading. Now I heard about faster ways of transferring data and they apparently involved downloading a small program and running it on the target, and then have that program receive more data over JTAG. Unfortunately I don't have any details. Dec 01 09:46:39 okay, you'll have to consult the mips datasheets - this totally depends on the MIPS Dec 01 09:47:55 so what is the fastest way to transfer data to a platform with an ARM? Does it involve downloading and running a small application first? Dec 01 09:48:23 yes Dec 01 09:48:43 the ARM's have a "Debug Communications Channel (DCC)" Dec 01 09:48:53 it's a 32-bit register, that can be written with little overhead Dec 01 09:49:10 interesting Dec 01 09:49:13 but it requires software running on the target to read that register, and to write the data to the target memory location Dec 01 09:49:43 so basically you set up the target with the base address, number of words to transfer, and a small algorithm that polls the DCC register, and writes whatever it gets to memory Dec 01 09:50:45 what are you currently using? the openwince jtag tools? Dec 01 09:51:12 no, we bought an Ashling probe Dec 01 09:51:44 I'm using their GDB server Dec 01 09:53:13 what speeds do you achieve? Dec 01 09:53:33 and are you talking about writing to RAM or to Flash? Dec 01 09:54:19 I haven't measured it, but I can go get coffee if I'm downloading a linux kernel (couple of MB) Dec 01 09:54:29 to RAM Dec 01 09:54:51 eventually we'll want to write everything through JTAG, flash and PROMs Dec 01 09:56:56 can't find much info about DCC though Dec 01 09:59:23 the DCC is something specific to the EmbeddedICE Unit of ARM7 and ARM9 (and ARM10 iirc) Dec 01 09:59:49 i'm just browsing the EJTAG specs Dec 01 10:00:04 it really seems to be a rather slow way of implementing debugging Dec 01 10:01:17 yeah, except for DMA Dec 01 10:01:24 but that's not in later MIPSes =( Dec 01 10:01:38 or was it later EJTAG.. I forget Dec 01 10:02:28 "MIPS EJTAG has two modes, one is "DMA" mode where the JTAG can cause CPU bus cycles directly, the other "PrAcc" is where the JTAG interface is used to respond to CPU memory accesses in a special range of memory (DMSEG, 0xFF200000)" Dec 01 10:03:38 "EJTAG version 2.0 in their chips. This allows the use of DMA transfers via JTAG which, while slow, is faster than the implementation of EJTAG v2.5 and v2.6 which do not support DMA transfers." Dec 01 10:04:43 exactly Dec 01 10:04:51 guess which one we have Dec 01 10:05:25 hehehe Dec 01 10:05:37 ok, PrAcc is a nice "idea", but it is almost bound to be slow Dec 01 10:06:31 especially if you have a probe on USB1.x Dec 01 10:07:29 btw, is there a USB2.0 FT2232 by now? Dec 01 10:07:51 haven't heard of one Dec 01 10:08:15 FTDI seems to have issues with 2.0 stuff Dec 01 10:08:41 "ft2232d: USB 2.0 Full Speed" hmm Dec 01 10:11:19 oh wait.. there was some internal limitation Dec 01 10:12:33 grmph.. nm me. I always mix up full speed and hi-speed Dec 01 10:14:40 heh, yeah, i have that problem, too Dec 01 10:14:45 full-speed sounds so promising Dec 01 10:19:34 yeah, I mean, there's always higher, but full is just full Dec 01 10:20:32 * Griffon26 is wading through dead links at mipstechnologies.com **** ENDING LOGGING AT Sat Dec 02 02:59:57 2006