> 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
