Peter,
Thanks for the feedback. I was able to get it working based on your advice.
In short:
- added bslskey section to memory.x (full file here:
http://pastebin.com/ejnUEjde ):
...
bslskey : ORIGIN = 0xffde, LENGTH = 0x0002 /* END=0xffe0, size 2*/
...
- Added bslskey section to linker output (full file here:
http://pastebin.com/jM0p04zm ):
...
.bslskey :
{
PROVIDE (__bslskey_start = .) ;
KEEP(*(.bslskey*))
_bslskey_end = . ;
} > bslskey
...
- Wrote short assembly file that specifies the value (full file here:
http://pastebin.com/kYsKzKAQ )
#ifndef BSLSKEY_VAL
#define BSLSKEY_VAL 0xffff
#endif
.section .bslskey, "a", @progbits
.global __bslskey
.word __bslskey
.equ __bslskey, BSLSKEY_VAL
- Added GCC options to make it use my linker script and the assembly file
msp430-gcc -mmcu=msp430f235 -T msp430.x -DBSLSKEY_VAL=0x0000 -o
bin/toggle.bin toggle.c bsls key.S
msp430-objdump now shows the .bslskey section at the right location, with
the right values. The behavior with the bootstrap loader is as indicated in
the datasheet: an incorrect BSL key does not erase main/info memory.
>From what I could tell, you can't specify symbol values in the linker
scripts, just their locations. So, I think that you need to have the
assignment in assembly at some point.
Thanks a ton. I would have wasted a lot of time on this without your
pointers.
-Doug
On Thu, Dec 29, 2011 at 12:15 PM, Peter Bigot <big...@acm.org> wrote:
> On Thu, Dec 29, 2011 at 9:51 AM, Doug Carlson <carl...@cs.jhu.edu> wrote:
> > Howdy. I'm trying to use the BSLSKEY feature of the msp430f235 and I'm
> > running into some trouble.
> >
> > >From the datasheet (http://www.ti.com/lit/ds/symlink/msp430f235.pdf,
> table
> > 7 note 9), I want to initialize the word at 0xFFDE to 0 so that it's
> > slightly harder for me to accidentally wipe out the DCO and ADC12
> > calibration constants stored in info segment A.
> >
> > This seems like a job for the const_sfrw macro. Here's what I tried (full
> > file here: http://pastebin.com/XvURBy69 ):
> >
> > #define BSLSKEY_ 0xFFDE
> > const_sfrw(BSLSKEY, BSLSKEY_);
> > BSLSKEY = 0;
> >
> > and here's the error that I get (full output/command here:
> > http://pastebin.com/4KZatFD0 ):
> > toggle.c:5:1: warning: data definition has no type or storage class
> > toggle.c:5:1: error: conflicting type qualifiers for ‘BSLSKEY’
> > toggle.c:4:1: note: previous declaration of ‘BSLSKEY’ was here
> >
> > The macro gets expanded to this (full output/command here:
> > http://pastebin.com/UPSU7b4n ):
> >
> > extern const volatile unsigned int BSLSKEY asm("__" "BSLSKEY");
> > BSLSKEY = 0;
>
> This declares BSLSKEY as an external symbol, then declares an untyped
> symbol of the same name that is non-const but has an initializer,
> hence the errors. const_sfrw is used to replace references to
> peripheral registers in the assembly code with references to a
> linker-defined symbol. I don't think you could use it to define a
> load-initialized value.
>
> > What am I missing here? Is this even the right way to say "I want to
> > initialize this location to this value"? Where does 0xFFDE even get into
> > this mix? Does it go in the linker script? That seems to be where the
> other
> > SFR locations are defined.
>
> Address 0xFFDE is not mapped to any known linker section. You'd need
> a custom memory.x to define the one-word region, then override the
> msp430.x* to add an output section for it, and either put the value
> into the linker script or use an asm file to place it as is done with
> crt0ivtbl.S.
>
> Or you may be able to combine it all into one line in the linker
> script without any special regions. Regardless, I think you need to
> do this in a custom linker script.
>
> Peter
>
> > Thanks in advance,
> > Doug Carlson
> >
> >
> ------------------------------------------------------------------------------
> > Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
> > infrastructure or vast IT resources to deliver seamless, secure access to
> > virtual desktops. With this all-in-one solution, easily deploy virtual
> > desktops for less than the cost of PCs and save 60% on VDI infrastructure
> > costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
> > _______________________________________________
> > Mspgcc-users mailing list
> > Mspgcc-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/mspgcc-users
> >
>
>
> ------------------------------------------------------------------------------
> Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
> infrastructure or vast IT resources to deliver seamless, secure access to
> virtual desktops. With this all-in-one solution, easily deploy virtual
> desktops for less than the cost of PCs and save 60% on VDI infrastructure
> costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
> _______________________________________________
> Mspgcc-users mailing list
> Mspgcc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mspgcc-users
>
------------------------------------------------------------------------------
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual
desktops for less than the cost of PCs and save 60% on VDI infrastructure
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
_______________________________________________
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
