Re: [Mspgcc-users] MSPDebug version 0.7
John Porubek writes: On Tue, May 25, 2010 at 9:01 PM, dan...@tortek.co.nz wrote: Hi John, I'm guessing that perhaps they use a different machine-type code for their binaries. I don't suppose you could email me one of these ELF32 files to have a look at? It might be nice to be able to work with the files produced by IAR as well. - Daniel Daniel, Sure, no problem. I'll send it to you separately so as not to burden the list. --John Hi John, These files do use a different machine-type code. Binaries produced by mspgcc have a code of 0x69, whereas this uses 0x430. If I ignore this, then symbols can be loaded. However, programming is a problem, because this file has no sections apart from the symbol and string tables. There's not enough information in the program header alone to reliably determine which parts should be flashed and which shouldn't (unless someone can tell me otherwise): Program Header: LOAD off0x0034 vaddr 0x0200 paddr 0x0200 align 2**1 filesz 0x memsz 0x0300 flags rw- LOAD off0x0034 vaddr 0xe000 paddr 0xe000 align 2**1 filesz 0x1ac8 memsz 0x1ac8 flags r-x LOAD off0x1afc vaddr 0xffe0 paddr 0xffe0 align 2**1 filesz 0x0020 memsz 0x0020 flags r-x The only way I can see is to ignore the first segment based on the fact that it lies outside of the MSP430F2274's code memory. However, this won't necessarily be reliable, because MSPDebug can't yet reliably identify chips with a 100% success rate. What I'm doing at the moment is looking for sections of type SHT_PROGBITS that have the SHF_ALLOC flag set, and then translating the addresses using the information in the program header. If anyone can suggest a reliable method of identifying segments which should be flashed, then I'll be happy to implement it. As an aside, I notice that running msp430-objcopy -O ihex results in an empty .hex file. - Daniel
[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
[Mspgcc-users] printf on msp430
Hi, my friends! Does MSPGCC have support for printf(), which automatically send data through USART0? It seems to me that it does have that function, but I just cannot find its definition. Am I right? If so, where is the source code? wating for your help. Thank you! -- Wang Hao, 1400 Townsend Drive,EERC 121 Houghton,MI
Re: [Mspgcc-users] MSPDebug version 0.7
On Wed, May 26, 2010 at 9:56 PM, dan...@tortek.co.nz wrote: John Porubek writes: On Tue, May 25, 2010 at 9:01 PM, dan...@tortek.co.nz wrote: Hi John, I'm guessing that perhaps they use a different machine-type code for their binaries. I don't suppose you could email me one of these ELF32 files to have a look at? It might be nice to be able to work with the files produced by IAR as well. - Daniel Daniel, Sure, no problem. I'll send it to you separately so as not to burden the list. --John Hi John, These files do use a different machine-type code. Binaries produced by mspgcc have a code of 0x69, whereas this uses 0x430. If I ignore this, then symbols can be loaded. However, programming is a problem, because this file has no sections apart from the symbol and string tables. There's not enough information in the program header alone to reliably determine which parts should be flashed and which shouldn't (unless someone can tell me otherwise): Program Header: LOAD off 0x0034 vaddr 0x0200 paddr 0x0200 align 2**1 filesz 0x memsz 0x0300 flags rw- LOAD off 0x0034 vaddr 0xe000 paddr 0xe000 align 2**1 filesz 0x1ac8 memsz 0x1ac8 flags r-x LOAD off 0x1afc vaddr 0xffe0 paddr 0xffe0 align 2**1 filesz 0x0020 memsz 0x0020 flags r-x The only way I can see is to ignore the first segment based on the fact that it lies outside of the MSP430F2274's code memory. However, this won't necessarily be reliable, because MSPDebug can't yet reliably identify chips with a 100% success rate. What I'm doing at the moment is looking for sections of type SHT_PROGBITS that have the SHF_ALLOC flag set, and then translating the addresses using the information in the program header. If anyone can suggest a reliable method of identifying segments which should be flashed, then I'll be happy to implement it. As an aside, I notice that running msp430-objcopy -O ihex results in an empty .hex file. - Daniel Hi Daniel, It sounds like dealing with IAR's version of an ELF-format file is turning into more work than is justified. I strongly suspect that the overwhelming majority of your target audience is using mspgcc. This *is* the Mspgcc-users mailing list, after all! I'll probably be converting over to mspgcc myself, one of these days. As I mentioned previously, I have successfully created a symbol file that works using nm. As for programming, I currently do that from IAR but, if I use MSPDebug, I can use Intel HEX (and lose the autoloading of symbols that the ELF format provides - not a huge deal). So, barring anyone else stepping up with the information you need, I can still limp along (just kidding!) using a few extra steps. BTW, while looking for more info. on IAR's ELF format, I found the following Known Problem in the Release notes for the MSP430 IAR Embedded Workbench product package version 5.10.1: EW20738: If you select ELF/DWARF as output format from the linker, only the ELF part with symbol information etc will be generated. The DWARF part is not provided which means that it is not possible to use the output file for debugging. The linker does not generate any warning message about this. I don't know if this sheds any useful light on the subject, but there it is. Thanks for your efforts, --John
