Re: [Openocd-development] making the target scripts a bit less verbose (?yvind Harboe)
?yvind Harboe wrote:
Which is better? (whatever better is)
This:
if {[info exists CHIPNAME]} {
set _CHIPNAME $CHIPNAME
} else {
set _CHIPNAME at91r40008
}
or this:
set _CHIPNAME [defaultval $CHIPNAME at91r40008]
As someone who USES OpenOCD but doesn't live and breathe it, I find
the if then version easier to read and understand
Anyone who has used any computer language can figure out what if/then
does (even though we may wonder about the difference between
CHIPNAME, _CHIPNAME, and $CHIPNAME)
In contrast, since I don't know TCL, I have to puzzle out whether
defaultval is a standard proc (as you post says), a language
keyword, or something else.
In my opinion the if/then version makes it easier for new users to
customize cfg files. And since most users will need to customize at
least one cfg file, I think simplicity trumps short files.
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
Re: [Openocd-development] Proposed change for STM32 Flash burner: at 0 as well as 0x8000000
At 01:32 PM 9/5/10, Spencer Oliver wrote: 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. (material deleted for brevity) 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 This is EXACTLY what I need. No changes to OpenOCD (aside from my cfg file), and no need to modify the configuration of other tools. Thank you. 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
[Openocd-development] Proposed change for STM32 Flash burner: at 0 as well as 0x8000000
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? 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
Re: [Openocd-development] Proposed change for STM32 Flash burner: at 0 as well as 0x8000000
At 02:48 PM 9/3/10, Ãyvind Harboe wrote: Shooting from he hip: what about the offset to gdb's load command? The short answer is I didn't know that gdb's load HAD an offset. The longer answer is that gdb may be invoked by Eclipse, Insight, CodeBlocks etc. In that case, specifying an offset is at best yet another configuration step that must be done. At worst, the GUI may not support adding such parameters. The syntax of load with an offset is also a bit annoying: Normally, the tools invoke gdb specifying the file to be debugged. Then the GUI issues gdb commands like target remote localhost: load To specify an offset on the load command, I have to re-specify the file load mypath/myfile.elf 0x800 So the configuration string now depends on the program being debugged. 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
Re: [Openocd-development] Proposed change for STM32 Flash burner: at 0 as well as 0x8000000
At 03:30 PM 9/3/10, Ãyvind Harboe wrote: But it does what you need? Yes. My hope was to move from possible to configure to easy to use. But it is certainly possible to use load with an offset. 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
Re: [Openocd-development] Proposed change for STM32 Flash burner: at 0 as well as 0x8000000
At 03:32 PM 9/3/10, Andreas Fritiofson wrote: Annoying how? The flash IS at 0x0800. Why would you want to link your program to 0? That if anything would be relying on the aliasing. Of course it works, otherwise the chip couldn't start, but does it alias the entire flash and not just enough to cover the vectors? Two years ago, the ST folks I asked didn't know the answer to that. Perhaps it's clarified in the docs today. I have found Flash-at-zero to be the common case for ARM7 from many vendors. Sometimes a register must be written to map the entire Flash at 0, more often 0 is the default. Perhaps this is not the case on Cortex - the STM32 is my only experience there. My first test project for STM32 was an LED-flasher program that Olimex ships with their STM-P103 board. It links at zero. I do not claim that this is the best project in the world, but it will be the first one that many people see, and it will not work as provided. The memory map diagram in the 3 June 2010 update to the STM32F103 datasheet labels the entire range 0 to 800_ with Aliased to Flash or system memory depending on BOOT pins. Whether or not this is accurate, I cannot say. My intent was to make it easier for people to get gdb and OpenOCD running. The volume of how do I do it traffic here and on SparkFun indicates to me that things could be made easier. But if the change seems unwise to the expects, I am happy to withdraw my proposal. Best regards, John Hartman ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
