The STM32 parts have Flash beginning at 0x8000000, 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 8000000.
One solution is to re-link my program to 8000000, 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 = 0x08000000;
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 0x00000000 0 0 0 $_TARGETNAME
flash bank $_FLASHNAME.2 stm32x 0x08000000 0 0 0 $_TARGETNAME
This claims that there are TWO Flash banks, one at 0 and one at
8000000. 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
8000000 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?
Best regards, John Hartman
NoICE Debugging Tools
http://www.noicedebugger.com
_______________________________________________
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
