Hi guys - we are using the Win32 MSPGCC package from sourceforge and are having a little trouble programing the microcontroller (MSP430F149). Via our JTAG programmer board we can connect to the micro, read the device identity, Vcc voltage and dump the register values etc ok. However when we try to download the binary program file we have problems. The messages we receive are: Debug window - "memory access error when loading section.txt". GDB Proxy Window - "Could not write to device memory" If we try to erase the device using - "monitor erase all", we get a message back stating "received command erase, could not preserve/restore device memory (12)" From the above it seems our JTAG programmer and the test board/connections are all working ok. The PC is running Win XP if this is of any relevance.Has any one any advice as to what our problem is? TIA regards rob
MSP430 Programming problem using MSPGCC win32 pkg - help!
Started by ●May 7, 2005
Reply by ●May 7, 20052005-05-07
"Rob" <rdsfal@iinet.net.au> wrote in message news:427c6eee$0$32055$5a62ac22@per-qv1-newsreader-01.iinet.net.au...> Hi guys - we are using the Win32 MSPGCC package from sourceforge and are > having a little trouble programing the microcontroller (MSP430F149). > > Via our JTAG programmer board we can connect to the micro, read the device > identity, Vcc voltage and dump the register values etc ok. However when we > try to download the binary program file we have problems. > > The messages we receive are: > > Debug window - "memory access error when loading section.txt". > GDB Proxy Window - "Could not write to device memory" > > > If we try to erase the device using - "monitor erase all", we get amessage> back stating "received command erase, could not preserve/restore device > memory (12)" > > From the above it seems our JTAG programmer and the test board/connections > are all working ok. The PC is running Win XP if this is of anyrelevance.Has> any one any advice as to what our problem is? >I had all sorts of similar problems when I started using a setup like yours - MSP430F449, parallel port JTAG, mspgcc. My target hardware was powered by an external DC supply. When using the JTAG however the board was also getting power through the JTAG connector. I found that if I unplugged the external supply whenever I was using the JTAG then all the problems went away. With the external power disconnected, and the JTAG connected I use the command: "msp430-jtag -ep a.out" to both erase then program the flash. Typing the command causes the board to power up through the jtag connector. Don't know if this is relevant to your problem but maybe? Regards, Richard. http://www.FreeRTOS.org
Reply by ●May 8, 20052005-05-08
"Richard" <noemail@given.com> wrote in message news:5f1fe.26940$G8.10067@text.news.blueyonder.co.uk...> > "Rob" <rdsfal@iinet.net.au> wrote in message > news:427c6eee$0$32055$5a62ac22@per-qv1-newsreader-01.iinet.net.au/////////////>> With the external power disconnected, and the JTAG connected I use the > command: > > "msp430-jtag -ep a.out" > > to both erase then program the flash. Typing the command causes the board > to power up through the jtag connector. > > Don't know if this is relevant to your problem but maybe? > > Regards, > Richard. > > http://www.FreeRTOS.org > > > >Hi Richard - thanks for the feedback, it could be the problem. I'll check it out during the week. regards rob
Reply by ●May 9, 20052005-05-09
Richard wrote:> With the external power disconnected, and the JTAG connected I use the > command: > "msp430-jtag -ep a.out"A related question: I have a binary file produced by IAR EW (using a release build instead of a debug build). Can this hex-ish file be turned into a file that's compatible with msp430-jtag? I need to ship binary, not source, to someone and I can't work out how to get IAR to burn this file (alone) into the MSP430.
Reply by ●May 9, 20052005-05-09
"Clifford Heath" <no@spam.please.net> wrote in message news:427effa9$0$8120$afc38c87@news.optusnet.com.au...> Richard wrote: > > With the external power disconnected, and the JTAG connected I use the > > command: > > "msp430-jtag -ep a.out" > > A related question: I have a binary file produced by IAR EW (using > a release build instead of a debug build). Can this hex-ish file > be turned into a file that's compatible with msp430-jtag? I need > to ship binary, not source, to someone and I can't work out how to > get IAR to burn this file (alone) into the MSP430.What format is produced by IAR EW? If it is non proprietary then I think you should be able to convert to ihex using msp430-objcopy. Regards, Richard. http://www.FreeRTOS.org
Reply by ●May 9, 20052005-05-09
Richard wrote:> What format is produced by IAR EW? If it is non proprietary then I think > you should be able to convert to ihex using > msp430-objcopy.Address lines look like: @ABCD Data lines look likez: 96 F1 3C 90 CC 00 02 20 5E 43 01 3C 4E 43 5E B3 and the closing line is: q That's all - easy to convert, but what format would be easiest?
Reply by ●May 10, 20052005-05-10
Clifford Heath wrote:> Richard wrote: > >> What format is produced by IAR EW? If it is non proprietary >> then I think you should be able to convert to ihex using >> msp430-objcopy. > > Address lines look like: > @ABCD > Data lines look likez: > 96 F1 3C 90 CC 00 02 20 5E 43 01 3C 4E 43 5E B3 > and the closing line is: > q > > That's all - easy to convert, but what format would be easiest?Sounds as if the above is an absolute address format, with no checking whatsoever. Then the next question is "what is ihex format". After which the conversion sounds trivial. -- Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net) Available for consulting/temporary embedded and systems. <http://cbfalconer.home.att.net> USE worldnet address!
Reply by ●May 10, 20052005-05-10
CBFalconer wrote:> Sounds as if the above is an absolute address format, with no > checking whatsoever.That was my guess. > Then the next question is "what is ihex> format". After which the conversion sounds trivial.If that means Intel Hex format, and msp430-jtag handles it, then I can do the rest. Thanks for the help. Clifford Heath.
Reply by ●May 10, 20052005-05-10
"Clifford Heath" <no@spam.please.net> wrote in message news:42808e0a$0$10301$afc38c87@news.optusnet.com.au...> CBFalconer wrote: > > Sounds as if the above is an absolute address format, with no > > checking whatsoever. > > That was my guess. > > > Then the next question is "what is ihex > > format". After which the conversion sounds trivial. > > If that means Intel Hex format, and msp430-jtag handles it, then > I can do the rest.I think Intel Hex is default of msp430-jtag. "msp430-jtag --help" for details. ihex is objcopy speak for Intel Hex. Regards, Richard. http://www.FreeRTOS.org
Reply by ●May 10, 20052005-05-10
Richard wrote:> "Clifford Heath" <no@spam.please.net> wrote in message >> CBFalconer wrote: > >>> Sounds as if the above is an absolute address format, with no >>> checking whatsoever. >> >> That was my guess. >> >>> Then the next question is "what is ihex >>> format". After which the conversion sounds trivial. >> >> If that means Intel Hex format, and msp430-jtag handles it, then >> I can do the rest. > > I think Intel Hex is default of msp430-jtag. > > "msp430-jtag --help" for details. > > ihex is objcopy speak for Intel Hex.The following exercpt from ppmanual (available in full at the URL in my sig below) may be useful. It is presented as a quotation to avoid line wrap at transmission, although the receiver may do funny things to it.> The structure of RBM files is best explained by first explaining HEX > files. > > A HEX file is made up entirely of printing characters, and can be > tranmitted and manipulated as a text file. A record, in a HEX file, > begins with the ":" character, has several fields containing only > the hexadecimal characters '0' through '9' and 'A' through 'F'. The > fields are as follows: > > > colon The character ":", beginning a record. > > length 2 hex characters, describing a value in the range > 0 to 255 only. This value specifies the length > of the remainder of the record. > > address 4 hex characters, describing an address in the > range 0 to 65535 (under some circumstances this > is considered a signed integer in the range - > 32768 to 32767). > > type 2 hex characters, describing a value in the range > 0 to 255 only. The interpretation of this value > is central to the use of RBM files. > > data (2 times length) hex characters. Interpretation > varies with use. > > checksum 2 hex characters, such that when each character > pair since the ":" is considered as a number in > the range (0..255), the sum MODULO 256 will be > zero. > > anything except a ":" may follow the checksum, and may be > used for formatting, comments, etc. It is always > ignored. > > Note that every data item, after the initial colon, can be expressed > as a one byte value, thus reducing storage requirements, > transmission time, etc. by at least a factor of 2. > > The original INTEL standard defined record types 0 and 1. Type 0 is > an absolute load code record, in which "address" describes the > machine address to be loaded with the first byte in the data field. > Type 1 is an end-of-file record, with length always zero, and > address describing an address to which execution control is to be > transferred. Type 0, when length is zero, is treated in the same > manner. By convention, a transfer address of zero in these > end-of-file records signifies that no control transfer is to be > made. > > > 12.2 RBM files > > RBM records are exact images of HEX records, except that the leading > colon and trailing checksum have been discarded, and that the > information is presented as 8 bit bytes in place of pairs of > hexadecimal characters. No trailing "anything" field is permitted, > and a new record begins immediately after the previous record ends. > Verification of storage is left up to the storage system on which > the files reside (typically CRC checksums over the storage blocks). > Thus RBM records can be discussed in exactly the same terms as HEX > records, and conversion between the systems is easy. > > > 12.2.1 RBM record types > > To preserve compatibility RBM files retain the original INTEL > definitions of record types 0 and 1, and add further types starting > at type 128 (080 hex). In all cases the length byte describes the > number of bytes in the data field, which may be zero. Additional > types are: > > 128 Relocatable data record. Exactly analogous to > the absolute data record (0), but the address > field describes the location with respect to the > base of the current module. > > 129 End module record. Address and length are zero. > > 130 Relocatable Code Module Header. The relocatable > records which follow are to be placed in a code > segment. The address field describes the total > length of the following code. The data field, > (which may be empty) may hold a name for the > segment of up to 60 characters. > > 131 Entrypoint descriptor. Address is a value > relative to the base of the current segment. > Data holds the name of the entrypoint, in Ascii > characters. > > 132 Absolute entry. Address is an absolute value, > which is to be used to resolve any referances to > the name in the data field (again in Ascii > characters). > > 133 External referance. Address is an index value > used by the linkage records which follow. The > data field holds a name, in Ascii, whose actual > value is described in some other module. Note > that the index in the address field will never be > less than 2, because indices 0 and 1 are reserved > to describe code and data module relative > relocation. > > 134 Data module header. As type 130, except that the > following data records are to be placed in the > data segment. > > 135 Alignment Record. Must only occur immediately > after a module header record. Causes the module > to adjust its location so that the absolute > location, modulo the address field, is zero. The > data field is unused. > > 136 Pcd module entry point. At linkage time this > value must have the high order 8 bits set to the > module number in which it occured, in the range 1 > to 127 (only 31 at present). The data field > contains the entry name. These records are used > to describe PCD linkages in terms of > segment/entrynumber pairs. The occurance of such > an entry point causes LINKER to assume that the > output is to be a PCD program. > > 137 Equate names. Not presently implemented. > Address field is unused. The data field contains > two Ascii names separated by the "=" character, > as in "name1=name2". Causes all referances to > name1 to be resolved as referances to name2. The > data field should not exceed 60 characters, thus > effectively limiting names to less than 30 > characters. > > 138 > > thru Reserved, not presently assigned. > > 143 > > Types 144 through 159 are reserved as linkage records, in which the > type modulo 16 is used as an operator. The address field (except > for types 152 through 154 below) contains an index, which refers to > an external referance record active within this module (or 0 or 1 to > specify the current code or data segment bases), and the data field > contains a list of 16 bit addresses, in high byte first format, > specifying a location relative to the current module beginning which > is to be adjusted. All operators discard any carrys and borrows, > and thus never cause arithmetic overflows. The operators currently > assigned are: > > > 144 Add lobytefirst words. The value of external > referance is added to the two bytes of the > module. > > 145 Subtract lobytefirst. The value of external > referance is subtracted from the two bytes of the > module. > > 146 Add byte. The value of external referance, low > order 8 bits only, is added to the byte of the > module. > > 147 Subtract byte. The value of external referance, > low order 8 bits only, is subtracted from the > byte of the module. > > 148 Add high byte. The value of external referance, > high order 8 bits only, is added to the byte of > the module. > > 149 Subtract high byte. The value of external > referance, high order 8 bits, is subtracted from > the byte of the module. > > 150 Add hibytefirst words. Similar to type 144, but > the module contents is treated as a high byte > first integer. Note that this does not affect > the value of the external. > > 151 Subtract hibytefirst words. As 150, but external > referance is subtracted from the module content. > > Types 152 through 154 are anonymous linkage records. Address > contains the value of the "external", rather than an index to it's > entry record. These records permit construction of one pass > assemblers and codegenerators, by postponing "fixup" operations to > linkage time. Since modules are in their most compact form at > linkage time, and since general code generation always requires a > two pass algorithm at some point, the linkage step is the most > efficient point at which to implement the second pass. > > > 152 Add lowbytefirst fixup linkage. > > 153 Add hibytefirst fixup linkage. > > 154 Add byte (8 bits only) fixup linkage. > > > 155 > > thru Unassigned operators. > > 159 > > > 160 > > thru Reserved for future use. > > 191 > > > 192 up Available for system dependant special operations > which cannot be handled by the existing types. > No reliance on portablity should be made when > these types are used.-- Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net) Available for consulting/temporary embedded and systems. <http://cbfalconer.home.att.net> USE worldnet address!
