Another board/chip shows the same effect. It might be a problem with the
erase command: if I erase it first with msp430-jtag, then it works and
the bytes are OK. Erasing from mspdebug doesn't appear to work:

(mspdebug) dis 0x8000
    08000: 31 40 00 21               MOV     #0x2100, SP
    08004: b2 40 80 5a 20 01         MOV     #0x5a80, &0x0120
    0800a: 3f 40 2c 00               MOV     #0x2c,   R15
    0800e: 0f 93                     TST     R15
[snip]
(mspdebug) erase
Erasing...
(mspdebug) dis 0x8000
    08000: 31 40 00 21               MOV     #0x2100, SP
    08004: b2 40 80 5a 20 01         MOV     #0x5a80, &0x0120
    0800a: 3f 40 2c 00               MOV     #0x2c,   R15
    0800e: 0f 93                     TST     R15
[snip]


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

------------------------------------------------------------------------------
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