Bad flash on the chip? From a quick look, it seems that the hex of the
readback (excluding address and checksum) shows zeros where there should be
ones, but never ones where there should be zeros. Seems implausible if
something's changing the data as it gets written. Might try erasing the
flash or writing patterns to it and seeing what you can read back.
At any rate, not a compiler/binutils problem, so my work here is done.
Peter
On Fri, Oct 15, 2010 at 9:19 AM, Michiel Konstapel <[email protected]>wrote:
> > If the object file is built for -mmcu=msp430x247, the text section
> > should start at 0x8000 and data at 0x1100. If for -mmcu=msp430x249,
> > the text is at 0x1100 and data at 0x0200. Check this with msp430-
> > objdump -s a.out. If that's right, it would seem to be an mspdebug
> > issue.
>
> Yup, it is for a 247. msp430-objdump says:
>
> Contents of section .text:
> 8000 31400021 b240805a 20013f40 2c000f93 1...@[email protected] .?@,...
> 8010 04241f83 cf430411 fc233f40 04000f93 .$...c.....@....
> ...
> Contents of section .data:
> 1100 00010100 ....
> Contents of section .vectors:
> ffe0 30803080 e8837284 30803080 30803080 0.0...r.0.0.0.0.
> fff0 a8805c80 30803080 c483ea80 30800080 ..\.0.0.....0...
>
> So that looks alright.
>
> It seems things are ending up in the right spot. However, if I flash a
> hex image, then dump it with hexout, the bytes are different. This'll
> probably get mangled in the email, but it's the first bit of sdiff
> output:
>
> :1080000031400021B240805A20013F402C000F93A4 |
> :1080000031400000B240805A20013F402C000F93C5
> :1080100004241F83CF430411FC233F4004000F932B |
> :1080100004241F83CF430400FC233F4004000F933C
> :1080200005242F839F4F0E8C0011FB233040FC84CE |
> :1080200005242F839F4F06880000FB233040B8842F
> :1080300030400C8C0000100050009000D000F00088 |
> :10803000304004880000100050009000D000F00094
> :108040000F4212C30F100F110F115FF332C203431F
> :108040000F4212C30F100F110F115FF332C203431F
> :108050007FF330414F93012432D230410F120E1280
> :108050007FF330414F93012432D230410F120E1280
> :108060000D120C12B01278803C413D413E413F411F
> :108060000D120C12B01278803C413D413E413F411F
> :10807000B1C0F000000000131F4262018F105FF3D7
> :10807000B1C0F000000000131F4262018F105FF3D7
> :1080800002241F42720130411F4264018F105FF3CE
> :1080800002241F42720130411F4264018F105FF3CE
> :1080900002241F42740130411F4266018F105FF3BA
> :1080900002241F42740130411F4266018F105FF3BA
> :1080A00002241F42760130410F120E120D120C12E3
> :1080A00002241F42760130410F120E120D120C12E3
> :1080B0001F422E0112C34F107FF31F930C242F93E6
> :1080B0001F422E0112C34F107FF31F930C242F93E6
> :1080C00005382F930A20B0129880073C0F930520A3
> :1080C00005382F930A20B0129880073C0F930520A3
> :1080D000B0127880023CB01288803C413D413E4164
> :1080D000B0127880023CB01288803C413D413E4164
> :1080E0003F41B1C0F000000000130F120E120D123C
> :1080E0003F41B1C0F000000000130F120E120D123C
> :1080F0000C124F43B0120A813C413D413E413F4189 |
> :1080F0000C120002100008013C413C413E4131405D
> :10810000B1C0F0000000001330414E4F7FF33F92AA |
> :10810000B000000000000013100002431402300011
> :10811000592C0F5F104F1881288158816A817A810C |
> :10811000190002010000188100001800020130015E
> :108120008A819A81AA81BA811F4282018F105FF3EE |
> :1081200082808A81820182810A02020082100C020E
> :1081300003241F4292013041B2F0EFFF820182938B |
> :1081300000200F42900000013040A0128201000197
>
> I don't know what to make of that, but it might be relevant.
> Michiel
>
> > -----Original Message-----
> > From: Peter Bigot [mailto:[email protected]]
> > Sent: vrijdag 15 oktober 2010 15:56
> > To: GCC for MSP430 - http://mspgcc.sf.net
> > Subject: Re: [Mspgcc-users] MSPDebug 0.11 and msp430f247
> >
> > The 247 and 249 do have different layouts, but I would have expected
> > mspdebug to write data to the addresses specified in the object file,
> > but perhaps it does something else.
> >
> > If the object file is built for -mmcu=msp430x247, the text section
> > should start at 0x8000 and data at 0x1100. If for -mmcu=msp430x249,
> > the text is at 0x1100 and data at 0x0200. Check this with msp430-
> > objdump -s a.out. If that's right, it would seem to be an mspdebug
> > issue.
> >
> > Peter
> >
> > On Fri, Oct 15, 2010 at 3:00 AM, Michiel Konstapel
> > <[email protected]>wrote:
> >
> > > Hi Daniel and others,
> > >
> > > I've been using mspdebug for flashing (mainly 2418s), which works
> > great.
> > > However, when I try to program a 247, there seems to be a problem:
> > > flashing completes without errors, but the program doesn't run.
> Maybe
> > > it gets loaded to a wrong location? Anything I can do to help you
> > debug it?
> > > The output looks perfectly fine:
> > >
> > > Trying to open UIF on /dev/ttyUSB0...
> > > Device: MSP430F249
> > > Erasing...
> > > Programming...
> > >
> > > It does identify the device as a 249, maybe causing it to assume a
> > > different memory layout?
> > >
> > > Kind regards,
> > > Michiel
> > >
> > >
> > >
> ---------------------------------------------------------------------
> > -
> > > -------- Download new Adobe(R) Flash(R) Builder(TM) 4 The new
> > Adobe(R)
> > > Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly
> > > Flex(R) Builder(TM)) enable the development of rich applications
> that
> > > run across multiple browsers and platforms. Download your free
> trials
> > today!
> > > http://p.sf.net/sfu/adobe-dev2dev
> > > _______________________________________________
> > > Mspgcc-users mailing list
> > > [email protected]
> > > https://lists.sourceforge.net/lists/listinfo/mspgcc-users
> > >
>
>
> ------------------------------------------------------------------------------
> Download new Adobe(R) Flash(R) Builder(TM) 4
> The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly
> Flex(R) Builder(TM)) enable the development of rich applications that run
> across multiple browsers and platforms. Download your free trials today!
> http://p.sf.net/sfu/adobe-dev2dev
> _______________________________________________
> Mspgcc-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/mspgcc-users
>
------------------------------------------------------------------------------
Download new Adobe(R) Flash(R) Builder(TM) 4
The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly
Flex(R) Builder(TM)) enable the development of rich applications that run
across multiple browsers and platforms. Download your free trials today!
http://p.sf.net/sfu/adobe-dev2dev
_______________________________________________
Mspgcc-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
