FYI, Peter Bigot was able to get me in the right direction on the mspgcc-users list.
In short, to specify a value for BSLSKEY in the binary, you have to tell the linker that there's a section of memory in this area, and (in assembly) specify what goes into that section: - 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 anything. >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. Haven't tied this in to the rest of the tinyos build process, but this should get you started if you run into the same problem or something similar to it. Thanks, Doug On Wed, Dec 28, 2011 at 11:27 AM, Doug Carlson <[email protected]> wrote: > Howdy. > On some MSP430 chips (I'm using the f235), the word below the interrupt > vectors is the "BSLSKEY." According to the f235's data sheet (Table 7, note > 9), when the value stored here is 0, an incorrect BSL password will *not* > trigger a mass erase (and when 0xAA55 is here, the BSL is disabled > entirely). I'd like to take advantage of this to make it slightly harder to > wipe out the DCO/ADC calibration data in information memory by accident. > > I tried to initialize this to 0 in my platform.h file (following the > example in msp430f235.h) with: > > #define BSLSKEY_ 0xFFDE > sfrw(BSLSKEY, BSLSKEY_); > BSLSKEY = 0; > > But I get the following error: > /home/carlson/local/src/tinyos-2.x/tos/platforms/toast/platform.h:6: > syntax error before `0xFFDE' > /home/carlson/local/src/tinyos-2.x/tos/platforms/toast/platform.h:6: > warning: return-type defaults to `int' > /home/carlson/local/src/tinyos-2.x/tos/platforms/toast/platform.h:6: > warning: data definition has no type or storage class > /home/carlson/local/src/tinyos-2.x/tos/platforms/toast/platform.h:7: > warning: type defaults to `int' in declaration of `BSLSKEY' > /home/carlson/local/src/tinyos-2.x/tos/platforms/toast/platform.h:7: > warning: data definition has no type or storage class > > (line 6 is the sfrw line, line 7 is the assignment). > > This seems to follow the method used in /usr/msp430/include/msp430f235.h > for the SFRs. For reference, this is an entry in msp430f235.h: > #define ADC12CTL0_ 0x01A0 /* ADC12 Control 0 */ > sfrw(ADC12CTL0, ADC12CTL0_); > > which gets expanded in app.c to > extern volatile unsigned int ADC12CTL0 __asm ("__""ADC12CTL0"); > > Any thoughts? Is this even the correct way to do this? The other option > seems to involve telling the linker to make a new section at 0xffde that's > two bytes long, then using the section __attribute__ directive to put the > variable there, but this seems kind of roundabout (adapted from this post > on e2e: > http://e2e.ti.com/support/microcontrollers/msp43016-bit_ultra-low_power_mcus/f/166/t/30995.aspx > ). > > > Thanks, > Doug Carlson >
_______________________________________________ Tinyos-help mailing list [email protected] https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
