On Tue, Nov 2, 2010 at 5:51 PM, Freddie Chopin wrote:
> On 2010-10-29 11:21, freddie_cho...@op.pl wrote:
>>
>> > Yep! Please send patches. I will also.
>>
>> I'll wait for maintainters' opinions, because if they don't like the idea
>> of separate cfg files any patch in that area would be just a
Xiaofan Chen wrote:
> > A GUI utility to do usual things would be even nicer - specify
> > interface/chip, press "connect", select image file, press "flash"
> > and that's it!
>
> That would be nice. Somewhat along the line of H-Jtag would be nice.
I like this idea as well. Not so much for my own
On Fri, Oct 29, 2010 at 10:24 AM, Peter Stuge wrote:
> freddie_cho...@op.pl wrote:
>> I think making OpenOCD more user-friendly and having SWD support
>> would be a major brakthrough for it, bot I think nothing is going
>> on in those areas...
>
> You must have missed the patches.
>
> I also think
freddie_cho...@op.pl wrote:
> I think making OpenOCD more user-friendly and having SWD support
> would be a major brakthrough for it, bot I think nothing is going
> on in those areas...
You must have missed the patches.
I also think user friendliness and SWD are good improvements. If you
can help
freddie_cho...@op.pl wrote:
> > I was considering this too. I strongly prefer a single file for the
> > entire family if possible, but it should not cost very much, if any,
> > performance.
>
> But in this situation single file costs performance,
Unless there is a way to tell devices apart.
On Fri, Oct 29, 2010 at 2:43 PM, Peter Stuge wrote:
> The ideal would be for openocd to identify the device. I guess IDCODE
> is not good enough to tell two devices with the same core apart, so
> we really have to rely on user input for it. :\
>
Ah, good idea. I think a new parameter is good to
2010/10/29 :
> "Xiaofan Chen" napisał(a):
> > Yet another solution is to have a generic cfg file with minimum
> > 4KB of SRAM but allow user to overwrite the generic config
> > file with bigger working area for better performance.
> >
> > Is this possible?
>
> Of course it is possible, but h
Xiaofan Chen wrote:
> > create a "general" cfg file and small dedicated cfg files for every
> > STM32 device available
>
> Yet another solution is to have a generic cfg file with minimum 4KB of SRAM
I think this was the idea.
> but allow user to overwrite the generic config file with bigger wor
On Fri, Oct 29, 2010 at 3:41 AM, Freddie Chopin wrote:
> Of course another solution would be to create a "general" cfg file and small
> dedicated cfg files for every STM32 device available (currently 89) - these
> would use (include) the "general" cfg. The structure of the target folder
> could be
Freddie Chopin wrote:
> another solution would be to create a "general" cfg file and small
> dedicated cfg files for every STM32 device available (currently 89) -
> these would use (include) the "general" cfg.
I was considering this too. I strongly prefer a single file for the
entire family if po
On 2010-10-28 20:15, Freddie Chopin wrote:
I'll try to check the flashing speed with various workareasizes later.
_WORKAREASIZE 0x4000 (16kB)
Start address 0x8000130, load size 129296
Transfer rate: 8 KB/sec, 12929 bytes/write.
_WORKAREASIZE 0x1000 (4kB)
Start address 0x8000130, load size 12
On 2010-10-28 19:53, Andreas Fritiofson wrote:
We should probably change it to the least common denominator within
the family, which is 8kB (maybe even 6?). Definitely, if you don't see
any significant reduction in flashing speed after reducing the
workareasize (8kB vs 2kB). That's likely depende
On Wed, Oct 27, 2010 at 10:53 PM, Freddie Chopin wrote:
> Hi!
>
> Someone has asked me for help with using OpenOCD + STM32F100 (8kB of RAM).
> After some time I've come to conclusion that the problem was caused by
> incorrect workareasize value, which in stm32.cfg is defined to be 16kB. With
> std
Øyvind Harboe wrote:
> >> Perhaps it would be a good idea for some target family scripts
> >> to have some required options, such as amount of RAM
> >> for chip? Perhaps with a default to the minimum possible
> >> amount of ram.
> >
> > Makes sense. I think in general it would be nice to tidy a lit
On Thu, Oct 28, 2010 at 8:42 AM, Peter Stuge wrote:
> Øyvind Harboe wrote:
>> Perhaps it would be a good idea for some target family scripts
>> to have some required options, such as amount of RAM
>> for chip? Perhaps with a default to the minimum possible
>> amount of ram.
>
> Makes sense. I thin
Øyvind Harboe wrote:
> Perhaps it would be a good idea for some target family scripts
> to have some required options, such as amount of RAM
> for chip? Perhaps with a default to the minimum possible
> amount of ram.
Makes sense. I think in general it would be nice to tidy a little in
tcl/target/
> However, I've always thought that OpenOCD somehow finds the amount of RAM
> that is available on the chip and will not allocate more than is possible?
Nope. There is no code in OpenOCD to figure this out.
Perhaps it would be a good idea for some target family scripts
to have some required optio
Hi!
Someone has asked me for help with using OpenOCD + STM32F100 (8kB of
RAM). After some time I've come to conclusion that the problem was
caused by incorrect workareasize value, which in stm32.cfg is defined to
be 16kB. With std cfg files flashing the device resulted in:
Error: JTAG-DP ST
18 matches
Mail list logo
