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 >
