On Tue, Nov 2, 2010 at 5:51 PM, Freddie Chopin freddie_cho...@op.pl 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
On Fri, Oct 29, 2010 at 3:41 AM, Freddie Chopin freddie_cho...@op.pl 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
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 working
2010/10/29 freddie_cho...@op.pl:
Xiaofan Chen xiaof...@gmail.com 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
On Fri, Oct 29, 2010 at 2:43 PM, Peter Stuge pe...@stuge.se 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
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.
BTW I
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,
On Fri, Oct 29, 2010 at 10:24 AM, Peter Stuge pe...@stuge.se 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
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
Ø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/ -
On Thu, Oct 28, 2010 at 8:42 AM, Peter Stuge pe...@stuge.se 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
Ø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
On Wed, Oct 27, 2010 at 10:53 PM, Freddie Chopin freddie_cho...@op.pl 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
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
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
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
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
17 matches
Mail list logo
