On Tue, Jan 10, 2012 at 2:58 PM, Roberto P. <padovan...@gmail.com> wrote:
> 2012/1/10 Mark Rages <markra...@gmail.com>
>>
>> On Mon, Dec 12, 2011 at 1:39 PM, Peter Bigot <big...@acm.org> wrote:
>> > On Mon, Dec 12, 2011 at 2:31 PM, Timothy Logan <timothy.lo...@gmail.com>
>> > wrote:
>> >> Hello,
>> >>
>> >>
>> >> My question: Is there an easier way to control which address in memory
>> >> a
>> >> variable/structure is stored in without having to muck around with
>> >> linker
>> >> scripts?
>> >
>> > You can use asm statements, as are done with the peripheral register
>> > declarations. Something like:
>> >
>> > volatile unsigned int specialdata __asm__("0x1320");
>> >
>> > will force the definition of specialdata to be placed at address 0x1320.
>> >
>>
>> Is there a syntax that will allow placement of a initialized const
>> variables in memory? (I want my bootloader to place its version
>> number in a well-defined place in flash memory.) Is this possible
>> without mucking with the linker script?
>>
>
> I do that programmatically, i.e. by code. We have a "factory data" structure
> with information like:
> - version of the structure (to handle software upgrade)
> - build number of the last run firmware (as above)
> - serial number
> - more specific stuff...
> - CRC16
>
> After reset, this structure is loaded from the information memory starting
> at address 0x1000 (it's the same in every MSP430); then we check if it is
> valid or not and then....you can do what is best for your application.
>
> The point is that information memory can be written and erased separately
> from the rest of the Flash, and we also have a builtin, runtime, routine to
> write this data in case of a firmware upgrade (last run build number lower
> of current one).
>
> Also, you can also easily "compile" a few lines long Intel Hex program file,
> which starts writing at address 0x1000 in order to load your data.
>
> The only limite is the 256 byte in total that you have....but it's ok for
> the kind of special data above.
>
> R#
We are already using the config space for calibration values etc.
Iwant the version of the bootloader to ride along with the
executableinstead, so a version upgrade doesn't wipe the cal values
and otherconfiguration.
Also 256 bytes is for newer chips, but I want firmware to becompatible
with earlier parts suffering erratum FLASH21, which limitsme to 128
bytes.
The datasheet giveth and the errata taketh away...
It is quite easy to add sections using the python tools shipped with
mspgcc3. But version numbers are tied closely to program code, so I'd
rather keep track of them in the source code.
Regards,Markmarkrages@gmail
------------------------------------------------------------------------------
Write once. Port to many.
Get the SDK and tools to simplify cross-platform app development. Create
new or port existing apps to sell to consumers worldwide. Explore the
Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
http://p.sf.net/sfu/intel-appdev
_______________________________________________
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
