On Tue, Jan 10, 2012 at 3: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);
In most of the 5xx/6xx chips including the FRAM variants the lowest
addressed information section is at 0x1800. There are a handful of
other exceptions including the 09x low voltage chips.
The new development series has declarations for __infoa through
__infod, depending on what's available on the chip, in <sys/crtld.h>
along with some other constants useful for this sort of application.
> 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.
Again some chips don't have 256 bytes; not all have four segments, and
not all have 128-byte segments. Across all chips for which I have
information the variations are:
ORIGIN = 0x1000, LENGTH = 0x0100 /* END=0x1100, size 256 as 2
128-byte segments */
ORIGIN = 0x1000, LENGTH = 0x0100 /* END=0x1100, size 256 as 4 64-byte
segments */
ORIGIN = 0x1080, LENGTH = 0x0080 /* END=0x1100, size 128 as 1
128-byte segments */
ORIGIN = 0x1800, LENGTH = 0x0100 /* END=0x1900, size 256 as 2
128-byte segments */
ORIGIN = 0x1800, LENGTH = 0x0200 /* END=0x1a00, size 512 as 4
128-byte segments */
ORIGIN = 0x1c00, LENGTH = 0x0060 /* END=0x1c60, size 96 as 1 96-byte
segments */
But this is a good point: if you want to place this sort of constant
in information memory as opposed to standard ROM, you can do so either
at runtime or at compile-time, without manipulating linker scripts. I
believe the syntax with LTS-20110716 is:
unsigned int calm __attribute__ ((section(".infomem"))) = 42;
unsigned int calm_nb __attribute__ ((section(".infomemnobits")));
where the former will place the corresponding data into information
memory (and, depending on your flash tool, into the MCU when that gets
programmed) and the latter will create a variable that is stored in
information memory but will not initialize it when programmed (useful
for constants that need to survive a code update). You can place
struct variable definitions the same way.
In the new development series the analogous definitions are:
unsigned int cala1 __attribute__ ((section(".infob"))) = 1;
unsigned int cala2 __attribute__ ((section(".infob.bss")));
as you are now allowed to place distinct values into specific
information segments, rather than treating the whole thing as a single
block and hoping you don't leak into infoa and blow away the
calibration values. The old section attributes are still supported,
but cannot co-exist in an executable with the new ones.
Peter
>
> R#
>
> ------------------------------------------------------------------------------
> 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
>
------------------------------------------------------------------------------
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
