On Sun, May 6, 2012 at 4:18 AM, Xiaofan Chen <[email protected]> wrote:
> On Sun, May 6, 2012 at 10:14 AM, Xiaofan Chen <[email protected]> wrote:
>>>> Similar test for STM32, ~120kB upload, core @ 8MHz, JTAG @ 1MHz - 31kB/s
>>>> vs. 29kB/s, not so impressive, but that may be the limit of the flash
>>>> memory.
>>>
>>> Probably the flash limit, or very close to it. You should see much
>>> greater gains for dump_image and upload to RAM.
>>
>> Now I only tested TI/Luminary LM3S1968 and the speed increase
>> is quite impressive compared to last time.
>>
>> mymacmini:bin xiaofanc$ ./openocd -f board/ek-lm3s1968.cfg
>> Open On-Chip Debugger 0.6.0-dev-00448-gac053a2 (2012-05-06-09:09)
>> Licensed under GNU GPL v2
>> For bug reports, read
>>        http://openocd.sourceforge.net/doc/doxygen/bugs.html
>> Info : only one transport option; autoselect 'jtag'
>> 500 kHz
>> Info : clock speed 500 kHz
>> Info : JTAG tap: lm3s1968.cpu tap/device found: 0x3ba00477 (mfg:
>> 0x23b, part: 0xba00, ver: 0x3)
>> Info : lm3s1968.cpu: hardware has 6 breakpoints, 4 watchpoints
>> Info : accepting 'telnet' connection from 4444
>> 500 kHz
>> cortex_m3 reset_config sysresetreq
>> Info : JTAG tap: lm3s1968.cpu tap/device found: 0x3ba00477 (mfg:
>> 0x23b, part: 0xba00, ver: 0x3)
>> target state: halted
>> target halted due to debug-request, current mode: Thread
>> xPSR: 0x01000000 pc: 0x00001330 msp: 0x20000100
>> flash 'stellaris' found at 0x00000000
>> dump_image filename address size
>> in procedure 'dump_image'
>> dumped 65536 bytes in 2.693520s (23.761 KiB/s)
>> dumped 131072 bytes in 5.382883s (23.779 KiB/s)
>> dumped 262144 bytes in 10.772668s (23.764 KiB/s)
>> auto erase enabled
>> wrote 262144 bytes from file demo3.bin in 8.257628s (31.002 KiB/s)
>> 500 kHz
>> cortex_m3 reset_config sysresetreq
>> Info : JTAG tap: lm3s1968.cpu tap/device found: 0x3ba00477 (mfg:
>> 0x23b, part: 0xba00, ver: 0x3)
>> Info : dropped 'telnet' connection
>>
>> Last time's result: the flash write is never above 18KB/sec for
>> LM3S1968. That was about a year ago.
>> http://comments.gmane.org/gmane.comp.debugging.openocd.devel/17877
>>
>> But I am not so sure if this is because of your mpsse driver or
>> the improvement in the main line. So I will report the result
>> using the vanilla git tree.
>>
>
> Hmm, the vanilla git tree is also very good, even slightly better.
> So in this case, probably the flash writing speed is approaching
> the limit for the Cortex M3 based LM3S1968

If I'm not mistaken, Spencer recently rewrote the stellaris flash
driver to use my asynchronous algorithm patch, which more or less does
away with latency-related performance issues. You should get better
download speed though, but you're running with a rather slow JTAG
clock (any reason why?) and your figures may be throughput bound.

Just a check... You're using the same board config file both times.
Are you changing it to use the ftdi driver instead of the old ft2232?
Both can be configured in the same OpenOCD binary and only the
configuration files select which one to use. There's a complete new
set of files in the interface/ftdi/ subdir that selects my driver
instead of the old one.

> mymacmini:lm3s1968 xiaofanc$ openocd -f board/ek-lm3s1968.cfg
> Open On-Chip Debugger 0.6.0-dev-00543-g908ee4d (2012-05-05-20:28)
> Licensed under GNU GPL v2
> For bug reports, read
>        http://openocd.sourceforge.net/doc/doxygen/bugs.html
> Info : only one transport option; autoselect 'jtag'
> 500 kHz
> Info : clock speed 500 kHz
> Error: couldn't read enough bytes from FT2232 device (70 < 81)
> Error: couldn't read from FT2232
> Error: Trying to use configured scan chain anyway...

These errors highlight the need for a new driver. It's not about performance.

/Andreas

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
OpenOCD-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openocd-devel

Reply via email to