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 <[email protected]> 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 <[email protected]> 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: [email protected] > > 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 > > [email protected] > > https://lists.sourceforge.net/lists/listinfo/mspgcc-users > >
