Quick question. Can the ARM-USB-OCD programmer be made to work with Rowley crossworks? If so I would definately buy one.
May I add my support here - I am also keen to know if this device works with CrossWorks ARM.
Rowley have their own USB programmer but it is more expensive, 99 pounds, and doesn’t have RS232. Perhaps they have little reason to support other programmers. On the other hand they have historically supported the Olimex Wiggler (parallel port) type. I have written to them about this.
They say that support for this programmer will be included in “a future release” of CrossWorks ARM. Sorry, that’s all they said, no estimated date or version number. Soon, I hope.
nscott:
They say that support for this programmer will be included in “a future release” of CrossWorks ARM. Sorry, that’s all they said, no estimated date or version number. Soon, I hope.
Olimex device support will be present in v1.7; right now the performance of the Olimex JTAG unit is not where we would want it and if we released anything we’d be slaughtered for the speed differential between the CrossConnect and the Olimex unit. As an example, the Olimex unit can load at about 100K/second into RAM vs the CrossConnect’s 300K/second. The real killer is programming Flash where the CrossConnect can do this at well over 100K/second whereas the Olimex unit is at 1K/second (yes, you read that right). So, we need to understand the issue before we release.
– Paul.
Programming what flash ?
Loading to ram is standard and basically identiical using JTAG for all different ARM7 chips.
A 3x speed difference can be important but also worth the wait if the price is right.
The flash loading times is an entiirely different matter. It depends on the target chips flash writing algorithm, How the jtag/flash programmer implements the flash writing algorithms
and how efficiently it can avoid beiing slowed down by the USB return trip times waiting for the target chip responses.
So my question is still, this 100x speed difference, exactly what are we comparing here ?
What chip? what programming algorithm ?
Magnus
mlu:
Programming what flash ?Loading to ram is standard and basically identiical using JTAG for all different ARM7 chips.
A 3x speed difference can be important but also worth the wait if the price is right.
The flash loading times is an entiirely different matter. It depends on the target chips flash writing algorithm, How the jtag/flash programmer implements the flash writing algorithms
and how efficiently it can avoid beiing slowed down by the USB return trip times waiting for the target chip responses.
So my question is still, this 100x speed difference, exactly what are we comparing here ?
What chip? what programming algorithm ?
Magnus
This is on the same target using the same software, downloading an app to flash over the DCC. The actual device and programming algorithm doesn’t matter, the problem is that if you communicate over the DCC you need to read data back from the ARM which results in high latency because of the USB overhead. The CrossConnect has intelligence and can do this completely locally resulting in zero bus traffic on the USB whilst polling the DCC status register on the ARM. On the FT2232 polling the DCC status requires a round trip with terrible performance.
Hence, we have an additional task to make the Olimex unit fast. Reading data back from the ARM is terribly slow on the FT2232 but is very rapid on the CrossConnect for exactly the same reasons above. We know we can make flashing faster, but it certainly won’t approach the speed of the CrossConnect and won’t approach the speed of the next design revision of the CrossConnect.
Having a USB JTAG adapter does not confer fast speed automatically.
– Paul.
Paul,
I thought you just D/L to RAM, and also put your own flash programming routine in RAM also. Then I thought you program the flash by executing that routine from RAM.
Since RAM is smaller than flash, this would require some iteration to program the entire flash range, but by doing a big block at a time the USB latency can be minimized.
I didn’t think there even was a way to program flash directly over JTAG? I never did understand this JTAG stuff to my satisfaction…
Eric
I’ve been using Crossworks with the Olimex paralled port JTAG interface for nearly 4 years and it has worked great. However, I recently bought a new computer that has no parallel port. So I also bought the ARM-USB-OCD device, anticipating Rowley releasing v1.7.
Rowley has just released v1.7 of Crossworks. I’ve installed v1.7 and the flash programming speed is terrible – slightly less than 2kB/s. Can anyone verify that this is typical flash programming speed for Crossworks/ARM-USB_OCD combination?
Jeff
Paul should enlight us on this, but as far OpenOCD can program with much higher speed it’s probably bad implementation of the CrossWorks F2232 drivers?
Best regards
Tsvetan
It is time for Amontec to help Paul at Rowley to reach a better speed for Crossworks + FTDI FT2232 solutions ( Amontec JTAGkey ).
Regards,
Laurent
The OpenOCD is cheating - with the Crosswork’s ability to handle the handshaking by itself this wasn’t necessary, but the rather simple FT2232 requires this for decent performance.
“arm7_9 fast_memory_access” and “arm7_9 dcc_downloads” are only safe when the target is running from a sufficiently high core clock. I did some calculations about the minimum ratio some time ago, but IIRC it was something like 2x-4x the JTAG frequency.
The OpenOCD then pretends that the target is always going to be fast enough to accept any data sent to it, and ignores the normally required handshake. This is usually working fine, but could fail, for example with memory that introduces a large number of waitstates.
Regards,
Dominic
Hello Laurent,
I do not believe that a brand X based FTDI2232 hardware is faster than
a brand Y based FTDI2232 hardware.
But in the last time I could read about some trouble the user had
with the ARM-USB-OCD hardware and the extra power supply function.
I think you will get the same speed with a JTAGkey. But the JTAGkey is
a 1in1 device. Therefore you can not get trouble with the 2 non
exiting function.
Btw, a JTAG speed comparison for different JTAG hardware can be found
here: http://www.yagarto.de/projects/jtagspeed/index.html
Best regards,
Michael
doubleshooter:
I’ve been using Crossworks with the Olimex paralled port JTAG interface for nearly 4 years and it has worked great. However, I recently bought a new computer that has no parallel port. So I also bought the ARM-USB-OCD device, anticipating Rowley releasing v1.7.Rowley has just released v1.7 of Crossworks. I’ve installed v1.7 and the flash programming speed is terrible – slightly less than 2kB/s. Can anyone verify that this is typical flash programming speed for Crossworks/ARM-USB_OCD combination?
Jeff
CrossWorks for ARM can program LPC2000 flash at about 70K per second using the FTDI device. You must use the RPC loader rather than the DCC loader\ to achieve this speed!
– Paul.
Paul,
Thanks, I’m getting 35kB/s flash programming speed. I had to set the JTAG clock divider to 4 to get reliable operation.
I’m now having problems with stepping through Thumb code. I set a break point and then try to “step over” and most of the time, it acts like a continue was issued. This behavior does not occur if I compile ARM code.
Jeff
doubleshooter:
Paul,Thanks, I’m getting 35kB/s flash programming speed. I had to set the JTAG clock divider to 4 to get reliable operation.
Indeed, RTCK provision (or lack thereof) is a problem with LPCs and SAM7s running slowly.
I’m now having problems with stepping through Thumb code. I set a break point and then try to “step over” and most of the time, it acts like a continue was issued. This behavior does not occur if I compile ARM code.
That’s rather strange. Is this new in v1.7? Is it linked to the JTAG adapter being used?
The FTDI support has been extensively tested on the various targets and devices before release. It’s been over a year since we released 1.6.