Re: [Mspgcc-users] Linker script for msp430x54xx
, or not. JMGross - Ursprüngliche Nachricht - Von: Peter Bigot An: mspgcc-users@lists.sourceforge.net Gesendet am: 27 Mai 2010 18:25:39 Betreff: Re: [Mspgcc-users] Linker script for msp430x54xx I'll get the basic patch for this into the queue for mspgcc4. Jens-Michael, would you say that for chips that have INFOA through INFOD, the sections should be named infoa (etc) and that infomem should be dropped on those chips? Do we need infoanobits (etc) for each of those as well? If the elf32msp430.sc template script is updated to make the bootloader, individual info, and combined infomem sections all optional driven by presence of the corresponding variable in the msp430all.sh script, just lik= e the fartext section is, is there any motivation to keep the forked elf32msp430_3 script? Peter -- ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] Linker script for msp430x54xx
Yes, the structure of the info areas is not very consistend across the many chips. Neither is the handling (write protection) nor the usage (calibration data). With all the new chips in the MSP series, things grow complicated more and more for a central script. :( And the slow-loading TI website and their structure (website as well as the separation of family guide and device datasheet) is no real help when requiring info about different processors. JMGross - Ursprüngliche Nachricht - Von: Peter Bigot An: mspgcc-users@lists.sourceforge.net Gesendet am: 03 Jun 2010 16:15:34 Betreff: Re: [Mspgcc-users] Linker script for msp430x54xx I started work on splitting out infoa through infod, but stalled: there are 47 data sheets to check, and it was only after the first pass through them that I realized that some chips with a 256b info section split it into two 128-byte chunks, and some into four 64-byte chunks. I need to revisit this, and verify that nobits actually does what it's supposed to, before that can be fixed. I expect infomem to be an alias section that overlays the info* sections available on the chip.
Re: [Mspgcc-users] Linker script for msp430x54xx
The patch for the basic problem (bad address for infomem on newer chips) has been submitted to mspgcc4. Once the moderator approves it it'll go in. In the meantime, it's integrated into the next branch of the git repository for mspgcc4. This patch also corrects the use of cc430x5123 which should have been cc430x5133; that affects both binutils and mspgcc4. I started work on splitting out infoa through infod, but stalled: there are 47 data sheets to check, and it was only after the first pass through them that I realized that some chips with a 256b info section split it into two 128-byte chunks, and some into four 64-byte chunks. I need to revisit this, and verify that nobits actually does what it's supposed to, before that can be fixed. I expect infomem to be an alias section that overlays the info* sections available on the chip. Peter On Fri, May 28, 2010 at 5:39 AM, JMGross msp...@grossibaer.de wrote: All MSPs have at least InfoA and InfoB, most have InfoA..InfoD. Many have calibration data on InfoA, the 1x series has not and the 5x series and others have the data in the TLV structure in a separate segment which is (normally) read-only (but maybe writable in an undeocumented way). This is the latest TI invention. Also, on the 5x series and some others, the InfoA segment has a separate write protection bit in the flash controller and is not erased by a mass erase if this bit is set. This protection would have been very useful for those devices with calibration data in InfoA, but there there is no protection adn the 5x series has no data to protect. And then TI has made another not-so-smart move, as this bit is toggled by writing a '1', so a read-modify-write of the register for setting a different bit, will write back this bit as '1' and disable protection, and subsequent changes will read it as '0' and write it as '0', leaving protection off, making it pretty useless as protection scheme. We should provide all, infoX, infoXnobits (what a telling name!) as well as infomem/infomemnobits. Maybe for those devices with protected InfoA, infomem should not include this area. Also, on some devices, such as the 54xxA series (not the ones without A) the bootloader sector is writable. It also contains a software flash fuse area which will disable JTAG access if not all ff or 00, but leave JTAG messaging still intact. No more fuse burning with overvoltage, and it is reversable by the running software. So more and different sections. I do not really understand how the infomemnobits works. On my linker scripts, its script code looks 100% identical to the infomem section. So how does the linker know not to put out code for one of them. I have no idea of the template script, so I don't know what to do and how, or not. JMGross - Ursprüngliche Nachricht - Von: Peter Bigot An: mspgcc-users@lists.sourceforge.net Gesendet am: 27 Mai 2010 18:25:39 Betreff: Re: [Mspgcc-users] Linker script for msp430x54xx I'll get the basic patch for this into the queue for mspgcc4. Jens-Michael, would you say that for chips that have INFOA through INFOD, the sections should be named infoa (etc) and that infomem should be dropped on those chips? Do we need infoanobits (etc) for each of those as well? If the elf32msp430.sc template script is updated to make the bootloader, individual info, and combined infomem sections all optional driven by presence of the corresponding variable in the msp430all.sh script, just lik= e the fartext section is, is there any motivation to keep the forked elf32msp430_3 script? Peter -- ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] Linker script for msp430x54xx
Cool! I'll check it out later. From what I have read in the GCC sources it will flag the infomemnobits section as belonging to SECTION_BSS and therefore will not emit any code to the linker if I understood correctly. I think the best strategy is to let GCC do the same for infomemnobits[AD]. Regards, Hans On Thu, 3 Jun 2010 09:15:34 -0500 Peter Bigot p...@peoplepowerco.com wrote: The patch for the basic problem (bad address for infomem on newer chips) has been submitted to mspgcc4. Once the moderator approves it it'll go in. In the meantime, it's integrated into the next branch of the git repository for mspgcc4. This patch also corrects the use of cc430x5123 which should have been cc430x5133; that affects both binutils and mspgcc4. I started work on splitting out infoa through infod, but stalled: there are 47 data sheets to check, and it was only after the first pass through them that I realized that some chips with a 256b info section split it into two 128-byte chunks, and some into four 64-byte chunks. I need to revisit this, and verify that nobits actually does what it's supposed to, before that can be fixed. I expect infomem to be an alias section that overlays the info* sections available on the chip. Peter On Fri, May 28, 2010 at 5:39 AM, JMGross msp...@grossibaer.de wrote: All MSPs have at least InfoA and InfoB, most have InfoA..InfoD. Many have calibration data on InfoA, the 1x series has not and the 5x series and others have the data in the TLV structure in a separate segment which is (normally) read-only (but maybe writable in an undeocumented way). This is the latest TI invention. Also, on the 5x series and some others, the InfoA segment has a separate write protection bit in the flash controller and is not erased by a mass erase if this bit is set. This protection would have been very useful for those devices with calibration data in InfoA, but there there is no protection adn the 5x series has no data to protect. And then TI has made another not-so-smart move, as this bit is toggled by writing a '1', so a read-modify-write of the register for setting a different bit, will write back this bit as '1' and disable protection, and subsequent changes will read it as '0' and write it as '0', leaving protection off, making it pretty useless as protection scheme. We should provide all, infoX, infoXnobits (what a telling name!) as well as infomem/infomemnobits. Maybe for those devices with protected InfoA, infomem should not include this area. Also, on some devices, such as the 54xxA series (not the ones without A) the bootloader sector is writable. It also contains a software flash fuse area which will disable JTAG access if not all ff or 00, but leave JTAG messaging still intact. No more fuse burning with overvoltage, and it is reversable by the running software. So more and different sections. I do not really understand how the infomemnobits works. On my linker scripts, its script code looks 100% identical to the infomem section. So how does the linker know not to put out code for one of them. I have no idea of the template script, so I don't know what to do and how, or not. JMGross - Ursprüngliche Nachricht - Von: Peter Bigot An: mspgcc-users@lists.sourceforge.net Gesendet am: 27 Mai 2010 18:25:39 Betreff: Re: [Mspgcc-users] Linker script for msp430x54xx I'll get the basic patch for this into the queue for mspgcc4. Jens-Michael, would you say that for chips that have INFOA through INFOD, the sections should be named infoa (etc) and that infomem should be dropped on those chips? Do we need infoanobits (etc) for each of those as well? If the elf32msp430.sc template script is updated to make the bootloader, individual info, and combined infomem sections all optional driven by presence of the corresponding variable in the msp430all.sh script, just lik= e the fartext section is, is there any motivation to keep the forked elf32msp430_3 script? Peter -- ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] Linker script for msp430x54xx
All MSPs have at least InfoA and InfoB, most have InfoA..InfoD. Many have calibration data on InfoA, the 1x series has not and the 5x series and others have the data in the TLV structure in a separate segment which is (normally) read-only (but maybe writable in an undeocumented way). This is the latest TI invention. Also, on the 5x series and some others, the InfoA segment has a separate write protection bit in the flash controller and is not erased by a mass erase if this bit is set. This protection would have been very useful for those devices with calibration data in InfoA, but there there is no protection adn the 5x series has no data to protect. And then TI has made another not-so-smart move, as this bit is toggled by writing a '1', so a read-modify-write of the register for setting a different bit, will write back this bit as '1' and disable protection, and subsequent changes will read it as '0' and write it as '0', leaving protection off, making it pretty useless as protection scheme. We should provide all, infoX, infoXnobits (what a telling name!) as well as infomem/infomemnobits. Maybe for those devices with protected InfoA, infomem should not include this area. Also, on some devices, such as the 54xxA series (not the ones without A) the bootloader sector is writable. It also contains a software flash fuse area which will disable JTAG access if not all ff or 00, but leave JTAG messaging still intact. No more fuse burning with overvoltage, and it is reversable by the running software. So more and different sections. I do not really understand how the infomemnobits works. On my linker scripts, its script code looks 100% identical to the infomem section. So how does the linker know not to put out code for one of them. I have no idea of the template script, so I don't know what to do and how, or not. JMGross - Ursprüngliche Nachricht - Von: Peter Bigot An: mspgcc-users@lists.sourceforge.net Gesendet am: 27 Mai 2010 18:25:39 Betreff: Re: [Mspgcc-users] Linker script for msp430x54xx I'll get the basic patch for this into the queue for mspgcc4. Jens-Michael, would you say that for chips that have INFOA through INFOD, the sections should be named infoa (etc) and that infomem should be dropped on those chips? Do we need infoanobits (etc) for each of those as well? If the elf32msp430.sc template script is updated to make the bootloader, individual info, and combined infomem sections all optional driven by presence of the corresponding variable in the msp430all.sh script, just lik= e the fartext section is, is there any motivation to keep the forked elf32msp430_3 script? Peter
Re: [Mspgcc-users] Linker script for msp430x54xx
Info segment A IS locked by default, while it does not hold any valuable data anymore. (and on those devices which DO hold valuable data, it is not protected at all). Maybe two different improvements in the design have crossed here, making one of them mostly obsolete again. You can still use the InfoA segment for device-specific data that shall not be erased during a firmware update. If supported by the programmer. (I guess, TI will get some advantage for selling their own programmers by this) The TLV table at 1xa00 is indeed an improvement as it tells not only calibration data but also lists the available modules. This could be useful for libraries which can see whether there are 2 or 4 USCI modules available etc. Since it does not provide information about the port mapping of the module signals (there's no mapping controller for the 54xx, even if it is listed in the newest family guide, where you could read this kind of info from), the use is limited, and the application software already needs to exactly know which peripherals are connected to which pin, so the TLV is pretty much useless. Except for the unique processor ID and the ADC calibration values. All I can think of is a program that automatically generates a proper master-includefile for a new processor by reading the processor type and the available modules and their positions from the TLV structure. The CAL_x values are no more needed for processors with an FLL module and an internal calibrated REFO. Therefore they dumped them. On MSPs with FLL+ module without internal REFO you'll still need them in case you don't have an external watch crystal available. IMHO, the universal clock system on the 54xx has removed all former drawbacks of previous clock module types. DCO can now reach maximum frequency, ACLK and SMCLK can be sourced form any clock, FLL is there and an itnernal reference and also a fallback source for the WDT, the VLO. JMGross - Ursprüngliche Nachricht - Von: Hans Nieuwenhuis An: mspgcc-users@lists.sourceforge.net Gesendet am: 27 Mai 2010 20:40:38 Betreff: Re: [Mspgcc-users] Linker script for msp430x54xx Hi, Thanks for the explanation about infomenobits. However I am not so sure about the the special purpose of info segment A. It can be seperately locked though. According to the user manual there is a newer method implemented in the 5xx devices which is located at 0x1a00 and further. This table is a lot more comprehensive and contain the calibrated ADC offsets. Furthermore the clock system has changed and is now accessed using UCSCTL0 - UCSCTL8. The old CAL_DCO_* and CAL_BC1_* pointers do not apply anymore. FLL is done inside the FLL now. Regards, Hans
[Mspgcc-users] Linker script for msp430x54xx
Hi all, Just found out that binutils (2.20.1, but also older revs.) installs incorrect linker files for the msp430x54xx parts. These parts have their bootloader starting at 0x1000, but as shown in the snippet blow that's where the linker puts the infomem section. Infomem should be four blocks of 128 bytes starting at 0x1800. bootloader(rx): ORIGIN = 0x0c00, LENGTH = 1K infomem(rx) : ORIGIN = 0x1000, LENGTH = 256 infomemnobits(rx) : ORIGIN = 0x1000, LENGTH = 256 What is the purpose of the sections infomem and infomemnobits as they both point the same start address? Can someone shed a light on this? Thanks, Hans
Re: [Mspgcc-users] Linker script for msp430x54xx
(I speak here with reference to the binutils patches in the mspgcc4 repository. Not sure which release you're using.) Chip-specific constants like that are stored in ld/emulparams/msp430all.sh. It appears ones for INFO and BOOT were added for some (but not all) chips, but are never referenced. They probably should be used in ld/scripttempl/ elf32msp430.sc in place of the hard-coded constants. (And maybe elf32msp430_3.sc; not sure why that family merits its own script). Did you discover this by analysis, or can you provide a short shell sequence that generates an elf32 with content in these sections so I can verify before/after behavior on various chips? Below are sections from the ld manual; I don't know specifically why one would want to put data into a memory section but not write it to the chip. ``.bootloader'' Defines the bootloader portion of the ROM (if applicable). Any code in this section will be uploaded to the MPU. ``.infomem'' Defines an information memory section (if applicable). Any code in this section will be uploaded to the MPU. ``.infomemnobits'' This is the same as the `.infomem' section except that any code in this section will not be uploaded to the MPU. Peter On Thu, May 27, 2010 at 5:33 AM, Hans Nieuwenhuis vz...@xs4all.nl wrote: Hi all, Just found out that binutils (2.20.1, but also older revs.) installs incorrect linker files for the msp430x54xx parts. These parts have their bootloader starting at 0x1000, but as shown in the snippet blow that's where the linker puts the infomem section. Infomem should be four blocks of 128 bytes starting at 0x1800. bootloader(rx): ORIGIN = 0x0c00, LENGTH = 1K infomem(rx) : ORIGIN = 0x1000, LENGTH = 256 infomemnobits(rx) : ORIGIN = 0x1000, LENGTH = 256 What is the purpose of the sections infomem and infomemnobits as they both point the same start address? Can someone shed a light on this? Thanks, Hans -- ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] Linker script for msp430x54xx
Hi Peter,
Forgot to mention I am using mspgcc4 from SVN with msp430-libc from
20100430.
Thanks for clearing up about the difference between the two sections.
For several of my projects I use these segments to store calibration
data. I usually used a bunch of shellscript to create a TITEXT file
containing the infomem bits and in the code used a fixed pointer to
reference this data.
This morning I wanted to include those data into the ELF directly and
by gazing over the linkerscript to find the correct section I
noticed the wrong address.
Here is a code snippet to test infomem
locations.
--8-
#include msp430x54xx.h
int a __attribute__ ((section (.infomem))) = 3;
int main (void) {
int i;
for (;;) {
i = a;
}
return 0;
}
8--
I used the following commands to compile it (from my Makefile):
/usr/local/msp430/bin/msp430-gcc -c -Dmsp430x5438 -mmcu=msp430x5438
-DMSP_CODE -O2 -g -Wall --std=gnu99 -Wa,-adhlns=testinfo.lst
testinfo.c -o testinfo.o
/usr/local/msp430/bin/msp430-gcc -Dmsp430x5438
-mmcu=msp430x5438 -DMSP_CODE -O2 -g -Wall --std=gnu99
-Wa,-adhlns=testinfo.lst testinfo.o --output infomem-test.elf -m
msp430x5438
/usr/local/msp430/bin/msp430-objcopy -O ihex
infomem-test.elf infomem-test.hex
/usr/local/msp430/bin/msp430-objdump
-h -S -C -t infomem-test.elf
infomem-test.lss
/usr/local/msp430/bin/msp430-nm -n infomem-test.elf
infomem-test.sym
ihex2titext infomem-test.hex infomem-test.titext
Continue in your reply:
On Thu, 27 May 2010 06:58:03 -0500
Peter Bigot p...@peoplepowerco.com wrote:
(I speak here with reference to the binutils patches in the mspgcc4
repository. Not sure which release you're using.)
Chip-specific constants like that are stored in ld/emulparams/msp430all.sh.
It appears ones for INFO and BOOT were added for some (but not all) chips,
but are never referenced. They probably should be used in ld/scripttempl/
elf32msp430.sc in place of the hard-coded constants. (And maybe
elf32msp430_3.sc; not sure why that family merits its own script).
Yeah, the msp430all.sh seems to have the correct locations defined
although I'd prefer to also have infomem split into their A, B, C, D
parts to let the linker check for overruns. I.e. if you want to update
some part of A, you can then copy A to B, erase A, copy-and-modify B
back to A. This is the way to do it in the smaller MSP's anyway.
Manually I modified the original msp430x5438.x to
have .infomem, .infomem[ABCD], .infomemnobits and .infomemnobits[ABCD]
and if you mix .infomem and .infomemA the linker will find overlapping
memory errors. This way you can choose to use the infomem as one big
chunk or use it as four seperate parts.
The old 3XX controllers don't seem to have infomem flash so that might
explain the seperate script. But indeed the INFO and BOOT values are
ignored in elf32msp430.sc.
Did you discover this by analysis, or can you provide a short shell sequence
that generates an elf32 with content in these sections so I can verify
before/after behavior on various chips?
Below are sections from the ld manual; I don't know specifically why one
would want to put data into a memory section but not write it to the chip.
``.bootloader''
Defines the bootloader portion of the ROM (if applicable). Any
code in this section will be uploaded to the MPU.
``.infomem''
Defines an information memory section (if applicable). Any code in
this section will be uploaded to the MPU.
``.infomemnobits''
This is the same as the `.infomem' section except that any code in
this section will not be uploaded to the MPU.
Peter
On Thu, May 27, 2010 at 5:33 AM, Hans Nieuwenhuis vz...@xs4all.nl wrote:
Hi all,
Just found out that binutils (2.20.1, but also older revs.) installs
incorrect linker files for the msp430x54xx parts. These parts have
their bootloader starting at 0x1000, but as shown in the snippet blow
that's where the linker puts the infomem section. Infomem should be
four blocks of 128 bytes starting at 0x1800.
bootloader(rx): ORIGIN = 0x0c00, LENGTH = 1K
infomem(rx) : ORIGIN = 0x1000, LENGTH = 256
infomemnobits(rx) : ORIGIN = 0x1000, LENGTH = 256
What is the purpose of the sections infomem and infomemnobits as they
both point the same start address? Can someone shed a light on this?
Thanks,
Hans
--
___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] Linker script for msp430x54xx
Hi Peter,
Here is a patch to fix the incorrect boot and info address and sizes.
--- elf32msp430.sc 2010-05-27 15:53:29.0 +0200
+++ /home/hans/msp430/elf32msp430.sc2010-05-27
15:48:37.0 +0200 @@ -41,6 +41,22 @@
FARTEXT_SECTION_MSP430=
fi
+if [ -z $BOOT_START ] ; then
+ BOOT_START=0x0c00
+fi
+
+if [ -z $BOOT_SIZE ] ; then
+ BOOT_SIZE=1K
+fi
+
+if [ -z $INFO_START ] ; then
+ INFO_START=0x1000
+fi
+
+if [ -z $INFO_SIZE ] ; then
+ INFO_SIZE=256
+fi
+
cat EOF
OUTPUT_FORMAT(${OUTPUT_FORMAT},${OUTPUT_FORMAT},${OUTPUT_FORMAT})
OUTPUT_ARCH(${ARCH})
@@ -50,9 +66,9 @@
${TEXT_REGION_MSP430}
data (rwx) : ORIGIN = $RAM_START, LENGTH = $RAM_SIZE
vectors (rw) : ORIGIN = $VECTORS_START, LENGTH =
$VECTORS_SIZE
- bootloader(rx): ORIGIN = 0x0c00, LENGTH = 1K
- infomem(rx) : ORIGIN = 0x1000, LENGTH = 256
- infomemnobits(rx) : ORIGIN = 0x1000, LENGTH = 256
+ bootloader(rx): ORIGIN = $BOOT_START, LENGTH = $BOOT_SIZE
+ infomem(rx) : ORIGIN = $INFO_START, LENGTH = $INFO_SIZE
+ infomemnobits(rx) : ORIGIN = $INFO_START, LENGTH = $INFO_SIZE
${HEAP_MEMORY_MSP430}
}
I tested it with msp430f5438 and msp430f1612 and both seem to have
their correct definitions now.
Regards,
Hans
On Thu, 27 May 2010 06:58:03 -0500
Peter Bigot p...@peoplepowerco.com wrote:
(I speak here with reference to the binutils patches in the mspgcc4
repository. Not sure which release you're using.)
Chip-specific constants like that are stored in ld/emulparams/msp430all.sh.
It appears ones for INFO and BOOT were added for some (but not all) chips,
but are never referenced. They probably should be used in ld/scripttempl/
elf32msp430.sc in place of the hard-coded constants. (And maybe
elf32msp430_3.sc; not sure why that family merits its own script).
Did you discover this by analysis, or can you provide a short shell sequence
that generates an elf32 with content in these sections so I can verify
before/after behavior on various chips?
Below are sections from the ld manual; I don't know specifically why one
would want to put data into a memory section but not write it to the chip.
``.bootloader''
Defines the bootloader portion of the ROM (if applicable). Any
code in this section will be uploaded to the MPU.
``.infomem''
Defines an information memory section (if applicable). Any code in
this section will be uploaded to the MPU.
``.infomemnobits''
This is the same as the `.infomem' section except that any code in
this section will not be uploaded to the MPU.
Peter
On Thu, May 27, 2010 at 5:33 AM, Hans Nieuwenhuis vz...@xs4all.nl wrote:
Hi all,
Just found out that binutils (2.20.1, but also older revs.) installs
incorrect linker files for the msp430x54xx parts. These parts have
their bootloader starting at 0x1000, but as shown in the snippet blow
that's where the linker puts the infomem section. Infomem should be
four blocks of 128 bytes starting at 0x1800.
bootloader(rx): ORIGIN = 0x0c00, LENGTH = 1K
infomem(rx) : ORIGIN = 0x1000, LENGTH = 256
infomemnobits(rx) : ORIGIN = 0x1000, LENGTH = 256
What is the purpose of the sections infomem and infomemnobits as they
both point the same start address? Can someone shed a light on this?
Thanks,
Hans
--
___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] Linker script for msp430x54xx
Indeed. When I started messing with the linker files for my bootloader project, I noticed it too, but forgot to report it. I use the 12/08 windows build of mspgcc3 (non-X) The differece between infomem and infomemnobits is that infomemnobits is dumped after relocating. Its contents are not put into the output file and not written to the MSP. So you can define variables placed there and won't cause an infomem write when flashing the chip. In addition, since the 54xx have the INFOA segment handled differently than the others, there should be separate sections. On CCE and IAR, all 4 INFO sections are separate rather than one huge section. And on some MSPs, INFOA contains unique calibration data and should be only usable on purpose and not by jsut placing something in infomem. JMGross - Ursprüngliche Nachricht - Von: Hans Nieuwenhuis An: mspgcc-users@lists.sourceforge.net Gesendet am: 27 Mai 2010 12:33:04 Betreff: [Mspgcc-users] Linker script for msp430x54xx Hi all, Just found out that binutils (2.20.1, but also older revs.) installs incorrect linker files for the msp430x54xx parts. These parts have their bootloader starting at 0x1000, but as shown in the snippet blow that's where the linker puts the infomem section. Infomem should be four blocks of 128 bytes starting at 0x1800. bootloader(rx): ORIGIN = 0x0c00, LENGTH = 1K infomem(rx) : ORIGIN = 0x1000, LENGTH = 256 infomemnobits(rx) : ORIGIN = 0x1000, LENGTH = 256 What is the purpose of the sections infomem and infomemnobits as they both point the same start address? Can someone shed a light on this?
Re: [Mspgcc-users] Linker script for msp430x54xx
I'll get the basic patch for this into the queue for mspgcc4. Jens-Michael, would you say that for chips that have INFOA through INFOD, the sections should be named infoa (etc) and that infomem should be dropped on those chips? Do we need infoanobits (etc) for each of those as well? If the elf32msp430.sc template script is updated to make the bootloader, individual info, and combined infomem sections all optional driven by presence of the corresponding variable in the msp430all.sh script, just like the fartext section is, is there any motivation to keep the forked elf32msp430_3 script? Peter On Thu, May 27, 2010 at 10:50 AM, JMGross msp...@grossibaer.de wrote: Indeed. When I started messing with the linker files for my bootloader project, I noticed it too, but forgot to report it. I use the 12/08 windows build of mspgcc3 (non-X) The differece between infomem and infomemnobits is that infomemnobits is dumped after relocating. Its contents are not put into the output file and not written to the MSP. So you can define variables placed there and won't cause an infomem write when flashing the chip. In addition, since the 54xx have the INFOA segment handled differently than the others, there should be separate sections. On CCE and IAR, all 4 INFO sections are separate rather than one huge section. And on some MSPs, INFOA contains unique calibration data and should be only usable on purpose and not by jsut placing something in infomem. JMGross - Ursprüngliche Nachricht - Von: Hans Nieuwenhuis An: mspgcc-users@lists.sourceforge.net Gesendet am: 27 Mai 2010 12:33:04 Betreff: [Mspgcc-users] Linker script for msp430x54xx Hi all, Just found out that binutils (2.20.1, but also older revs.) installs incorrect linker files for the msp430x54xx parts. These parts have their bootloader starting at 0x1000, but as shown in the snippet blow that's where the linker puts the infomem section. Infomem should be four blocks of 128 bytes starting at 0x1800. bootloader(rx): ORIGIN = 0x0c00, LENGTH = 1K infomem(rx) : ORIGIN = 0x1000, LENGTH = 256 infomemnobits(rx) : ORIGIN = 0x1000, LENGTH = 256 What is the purpose of the sections infomem and infomemnobits as they both point the same start address? Can someone shed a light on this? -- ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] Linker script for msp430x54xx
Hi, Thanks for the explanation about infomenobits. However I am not so sure about the the special purpose of info segment A. It can be seperately locked though. According to the user manual there is a newer method implemented in the 5xx devices which is located at 0x1a00 and further. This table is a lot more comprehensive and contain the calibrated ADC offsets. Furthermore the clock system has changed and is now accessed using UCSCTL0 - UCSCTL8. The old CAL_DCO_* and CAL_BC1_* pointers do not apply anymore. FLL is done inside the FLL now. Regards, Hans On Thu, 27 May 2010 17:50:50 +0200 JMGross msp...@grossibaer.de wrote: Indeed. When I started messing with the linker files for my bootloader project, I noticed it too, but forgot to report it. I use the 12/08 windows build of mspgcc3 (non-X) The differece between infomem and infomemnobits is that infomemnobits is dumped after relocating. Its contents are not put into the output file and not written to the MSP. So you can define variables placed there and won't cause an infomem write when flashing the chip. In addition, since the 54xx have the INFOA segment handled differently than the others, there should be separate sections. On CCE and IAR, all 4 INFO sections are separate rather than one huge section. And on some MSPs, INFOA contains unique calibration data and should be only usable on purpose and not by jsut placing something in infomem. JMGross - Ursprüngliche Nachricht - Von: Hans Nieuwenhuis An: mspgcc-users@lists.sourceforge.net Gesendet am: 27 Mai 2010 12:33:04 Betreff: [Mspgcc-users] Linker script for msp430x54xx Hi all, Just found out that binutils (2.20.1, but also older revs.) installs incorrect linker files for the msp430x54xx parts. These parts have their bootloader starting at 0x1000, but as shown in the snippet blow that's where the linker puts the infomem section. Infomem should be four blocks of 128 bytes starting at 0x1800. bootloader(rx): ORIGIN = 0x0c00, LENGTH = 1K infomem(rx) : ORIGIN = 0x1000, LENGTH = 256 infomemnobits(rx) : ORIGIN = 0x1000, LENGTH = 256 What is the purpose of the sections infomem and infomemnobits as they both point the same start address? Can someone shed a light on this? -- ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
