Wow, well spotted. I'll write some FFs, and check with another board.
Strange that it does work when I flash it with msp430-jtag.

> At any rate, not a compiler/binutils problem, so my work here is done.

Compiler/binutils man, AWAY! *heroic stance and liftoff*
Thanks for taking a look :)
Michiel

> -----Original Message-----
> From: Peter Bigot [mailto:[email protected]]
> Sent: vrijdag 15 oktober 2010 16:37
> To: GCC for MSP430 - http://mspgcc.sf.net
> Subject: Re: [Mspgcc-users] MSPDebug 0.11 and msp430f247
> 
> 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

Reply via email to