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 129296
Transfer rate: 4 KB/sec, 12929 bytes/write.
So there is a decrease...
It's a good idea in my opinion, but I'm not sure whether it's possible -
the MCU Device ID register only shows the "family" (low-, medium-,
high-density, connectivity, value, etc.), so that's not enough - maybe
checking flash size would allow OpenOCD to determine the RAM size...
I'll investigate this more later.
There are some cases where the amount of available RAM cannot be
determined - there are some devices of the same family that have the
same flash size but different amount of RAM. E.g.:
STM32F105VB (CL), 128kB flash, 32kB RAM
STM32F107RB (CL), 128kB flash, 48kB RAM
However, that is enough to determine max amount of RAM with "small"
error - there are such pairs with (more or less) "adjacent" amounts of
ram (4/6, 6/10, 32/48, 48/64, etc.). I'd even like to do that, but the
mechanics of OpenOCD is still a big mystery for me - in
stm32x_write_block() (stm32x.c) the buffer size to be allocated is fixed
at 16kB, and this file does nothing with workareasize defined in cfg
files (I think...).
What is the reason to use fixed buffer size of 16kB? Shouldn't that be
changed as there are chips with more RAM and those could benefit from
higher workareasize (I cannot check, I only have chips with 20kB of RAM).
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 changed to
target
- st
- stm32
stm32f103rb.cfg
stm32f105v8.cfg
...
- str7
str710.cfg
str711.cfg
...
- str9
...
- nxp
- lpc17xx
...
- lpc2xxx
...
and so on.
I think that would improve the "OpenOCD experience" for the users...
It's still not very user-friendly );
I could try to do some patches, but I'd first like to hear your opinions.
4\/3!!
_______________________________________________
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
