On 03/09/2010 20:29, John Hartman (NoICE) wrote:
The STM32 parts have Flash beginning at 0x800, and OpenOCD's
stm32x.c places the Flash there regardless of the address used in the
flash command in the cfg file.
The chips have two pins that can be jumpered to specify what appears at
address 0: Flash, RAM, or the boot loader. For embedded work, I think
Flash will be the most common case.
But if I link my program at zero, it is a pain to burn my program,
because OpenOCD tells gdb there is only RAM at 0, with Flash at 800.
One solution is to re-link my program to 800, and rely on aliasing
of the vector table to 0. This works, but is a little annoying.
I would like to propose the following changes to allow Flash at zero:
1) In the file flash/stm32x.c, function stm32x_probe, remove or comment
out the explicit setting of bank-base:
// Don't fill in the base: get it from the cfg file
// bank-base = 0x0800;
bank-size = (num_pages * page_size);
(etc.)
2) In the stm32.cfg, change
flash bank $_FLASHNAME stm32x 0 0 0 0 $_TARGETNAME
to
flash bank $_FLASHNAME.1 stm32x 0x 0 0 0 $_TARGETNAME
flash bank $_FLASHNAME.2 stm32x 0x0800 0 0 0 $_TARGETNAME
This claims that there are TWO Flash banks, one at 0 and one at 800.
By having two banks, users can locate their code at either location, as
they prefer, without needing to modify the cfg file.
Note that this would break existing cfg files, moving the Flash from
800 to 0. This could be remedied by using a non-zero value for one
of the other parameters (bus width etc) to mean new style, and only
using the specified base address in that case. (Or more formally, one
might add a new algorithm instead of stm32x that does this)
What do people think?
Just use the virtual bank cmd, that s what it there for
flash bank $_FLASHNAME stm32x 0 0 0 0 $_TARGETNAME
flash bank vbank0 virtual 0x 0 0 0 $_TARGETNAME $_FLASHNAME
Cheers
Spen
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
