mspgcc-users-requ...@lists.sourceforge.net wrote:
Subject:
Re: [Mspgcc-users] BSL InfoSegs Error
From:
Chris Liechti <cliec...@gmx.net>
Date:
Tue, 12 Jan 2010 00:10:45 +0100
To:
"GCC for MSP430 - http://mspgcc.sf.net";
<mspgcc-users@lists.sourceforge.net>
To:
"GCC for MSP430 - http://mspgcc.sf.net";
<mspgcc-users@lists.sourceforge.net>
Larry Young schrieb:
Thanks to this group, I have been using the msp430/gcc toolchain and the
BSL updater "bsl-updater.nsi" successfully with an MSP430F448.
Yesterday I added some fixed parameters to be stored in the information
segments at 0x1000-0x10ff, by adding a const array of ints with the
__attribute((section(".infomemA"))) syntax and adding this section to
the linker command line. The resulting hex file shows the new values
correctly, and I can program the MSP430 with msp430-jtag through the
JTAG hardware. All good, so far.
Unfortunately, when I use the same hex file as the input to the
bsl-updater and create the standalone updater.exe and run it, the update
process dies after:
did you try msp430-bsl on the command line too? you could also
experiment with -D, -DDD (enables more or less debug messages)
Download on COM4...
MSP430 Bootstrap Loader Version: 2.0
Mass Erase...
Transmit default password ...
Invoking BSL...
Transmit default password ...
Current bootstrap loader version: 1.60 (Device ID: f449)
Program ...
40978 bytes programmed.
Write InfoSegs ...
i do not find this string in the sources. is this an original msp430-bsl
from mspgcc?
An error occoured:
NAK received (wrong password?)
it would also report an error if the information memory was not erased
(it would be by default when using -e) or if the hexfile contains the
same segment twice with different data.
An error occurred, could not write target.
Aborted.
Can anyone advise me as to why adding data in the 0x1000-0x10ff range
would cause the BSL to fail? What is happening at the line "Write
InfoSegs"?
good question as i don't find something like that in my sources ;-)
information segments should be programmed along with the normal "Program
..." that happens above.
chris
Chris -
Many thanks for your very fast and very helpful response. Now I see
that this is a version-control/path problem in my system. My
msp430-bsl.exe (circa 2004) is trying to save the Information Segments
from the target, then mass-erase, re-program, and then rewrite the saved
InfoSegs. As you correctly observed, if the hexfile has data to write
to the InfoSegs region, then this last step is overwriting the region
and triggers the error. I installed the 2008 msp430 toolchain
distribution and now this problem does not occur, because there is no
"Write InfoSegs" step.
Clearly, I had modified my (2004) msp430-bsl.exe, and I apologize for my
forgetfulness. However, after I downloaded the official msp430-bsl.exe
from the SourceForge archive of November, 2004, the same spurious "Write
InfoSegs" programming step occurs. The msp430-bsl.exe executable itself
must be invoking another module from somewhere on my computer. I would
expect such a secondary effect if running as a Python script, but does
the .exe version also depend on some other modules? I have searched as
many locations as practical for the "Write InfoSegs" string and cannot
find anything.
In short, the immediate problem is solved but I am still curious about
the source of the "Write InfoSegs" step. Thanks again for your help,
and for creating this superb MSP430 toolkit.
Larry
