On Fri, 2009-04-03 at 09:33 +0100, Spencer Oliver wrote:
> Currently we save/restore the registers after every algorithm run - during a
> flash write this could mean multiple runs to complete. I would like to
> change the scheme so that we save at the start of a flash algorithm and
> restore when p
Spencer Oliver wrote:
>> This works with a configured 72 MHz clock on the target,
>> in my case from the preprogrammed board test application.
>>
>> The performance of the target flash controller is now the main
>> limiting factor.
>>
>>
>
> I would commit this aswell, this could also be appli
Spencer Oliver wrote:
>> This works with a configured 72 MHz clock on the target,
>> in my case from the preprogrammed board test application.
>>
>> The performance of the target flash controller is now the main
>> limiting factor.
>>
>>
>
> I would commit this aswell, this could also be appli
> This works with a configured 72 MHz clock on the target,
> in my case from the preprogrammed board test application.
>
> The performance of the target flash controller is now the main
> limiting factor.
>
I would commit this aswell, this could also be applied to the arm4_5 target.
Currently w
The follow patch improves algorithm performance slightly by only marking
registers that has really changed as dirty.
Tested with flash writing for STM32.
With the latest changes I can now get the following performance:
STM32-P103 board, FT2232 JTAG adapter
16 kB, jtag_khz 500
download to t
Spencer Oliver wrote:
>
>
>> Does anyone have any objections to committing this patch?
>>
>> It's relatively straightforward to revert and reportely
>> improves performance significantly and hurts noone(so far).
>> When we commit it we have a record of it at least
>>
>>
>
> Fine wit
> Does anyone have any objections to committing this patch?
>
> It's relatively straightforward to revert and reportely
> improves performance significantly and hurts noone(so far).
> When we commit it we have a record of it at least
>
Fine with me, i would also #if 0 the first scan_inou
Does anyone have any objections to committing this patch?
It's relatively straightforward to revert and reportely improves performance
significantly and hurts noone(so far). When we commit it we have a record
of it at least
--
Øyvind Harboe
PayBack incident management system
Reduce costs and
Øyvind Harboe a écrit :
> I think this change should be committed if it helps some and
> hurts noone...
>
>
>
>
I tried it and found huge improvements. There is still a problem not
related to that one, it always fails to program the first time.
This can't be an STM32 problem since I have never e
I think this change should be committed if it helps some and
hurts noone...
--
Øyvind Harboe
PayBack incident management system
Reduce costs and increase quality, free Starter Edition
http://www.payback.no/index_en.html
___
Openocd-development mailing
No difference in performance with ZY1000. (10kBytes/s @ 500kHz).
I get these errors upon reset init(w/stm32.cfg) with and without your changes.
SWJ-DP OVERRUN - check clock or reduce jtag speed
dcb_dhcsr 0x1010001, nvic_shcsr 0x0, nvic_cfsr 0x0, nvic_bfar 0x27f4
SWJ-DP OVERRUN - check clock o
Øyvind Harboe wrote:
Patch? :-)
I'd like to take those changes for a spin.
Patch as .txt
Index: src/target/cortex_swjdp.c
===
--- src/target/cortex_swjdp.c (revision 1435)
+++ src/target/cortex_swjdp.c (working copy)
@@ -
Øyvind Harboe wrote:
> Patch? :-)
>
> I'd like to take those changes for a spin.
>
>
>
Im not sure about current path practices, but here is a svn diff from trunk
Regards
Magnus
[lundin trunk 23:17:58]$svn diff
Index: src/target/cortex_swjdp.c
=
Patch? :-)
I'd like to take those changes for a spin.
--
Øyvind Harboe
PayBack incident management system
Reduce costs and increase quality, free Starter Edition
http://www.payback.no/index_en.html
___
Openocd-development mailing list
Openocd-developm
Hi list
I just have had enough free time to check out my STM32-P103 boards,
( and update from a version of OpenOCD that was current a year and a
half ago, my head spins :) )
My understanding of why the STM32 flash write is slow is as follows:
- flash write uses run_algorithm that saves
> Hi,
> > Originally the stm32 had a register so you could query the
> ram size -
> > ST in their wisdom have removed this feature !!
> You can query the ram size and flash size by visiting
> 0x17E0 in the latest STM32 chips.
>
> 2009-03-24
>
>
> Best Rega
Hello,
On Mon, Mar 23, 2009 at 3:13 PM, Spencer Oliver wrote:
> I really would like a target that issues the following line - but so far
> have not found one.
> LOG_ERROR("BUG: Why does this fail the first time");
>
I got this on my Olimex STM32-H103 board, which has a STM32F103 RBT6,
with a
Hi,
> Originally the stm32 had a register so you could query the ram size - ST in
> their wisdom have removed this feature !!
You can query the ram size and flash size by visiting 0x17E0 in the latest
STM32 chips.
2009-03-24
Best Regards, Simon Qian
SimonQian(simonq...@simonqian.com) ---
> >> I also tried to use OpenOCD's RLink interface: 7.241484 kb/s.
> >> Much slower than the native RFlasher application.
>
> > You could try the following patch - it will add a couple of
> K to the
> > speed (my tests anyway 13-14kb/sec).
>
> Which one? The archive-link and the one attached t
Spencer Oliver wrote:
>> But I still think it's slow. When I write the same image to a
>> STM Primer using RFlasher 7, it only takes ~3 seconds.
>>
>> I also tried to use OpenOCD's RLink interface: 7.241484 kb/s.
>> Much slower than the native RFlasher application.
> You could try the following
> Ok, now I get:
>
>wrote 85144 byte from file main.elf in 9.609000s (8.653183 kb/s)
>
> But I still think it's slow. When I write the same image to a
> STM Primer using RFlasher 7, it only takes ~3 seconds.
>
> I also tried to use OpenOCD's RLink interface: 7.241484 kb/s.
> Much slower t
Spencer Oliver wrote:
>> I'm using a JTAGkey-Tiny to program my STM32F103VBT6 CPU, but
>> the flash performance seems to be _very_ low.. (around 6 kb/s).
> The write time will include the erase, this can be speeded up by using the
> mass erase, eg.
> stm32x mass_erase 0
> flash write_image $filen
> -Original Message-
> From: openocd-development-boun...@lists.berlios.de
> [mailto:openocd-development-boun...@lists.berlios.de] On
> Behalf Of Thomas Kindler
> Sent: 21 March 2009 19:20
> To: openocd-development@lists.berlios.de
> Subject: [Openocd-dev
Hi!
I'm using a JTAGkey-Tiny to program my STM32F103VBT6 CPU, but the flash
performance seems to be _very_ low.. (around 6 kb/s).
I already tried to enable the PLL and setting jtag_khz to 6000 (which
works), but it doesn't get any faster. Here's my openocd.cfg:
source [find board/stm32f10x_1
24 matches
Mail list logo
