I was just asked by a local college prof about the idea of modifying
his CS162 course (a winter term, coming up) to use the MSP430
processor. His students need to write a simple assembler tool of
their own, as one of two class projects they must do, and it needs to
generate binary code that can be simulated. (The second project is,
in fact, the simulator.) He is thinking about the idea of having them
do a small subset of the MSP430 instructions and, if possible, taking
their own assembler outputs and loading them into an actual MSP430 on
their own eZ430-F2013 development tools (lab fee used to buy those.)

The problem here is that the students are writing their own assembler
and generating their own binary code result, using masking and ioring
of bits (which is part of their learning experience.) This code sits
in an array in a C++ program they write on the IBM PC using the
Microsoft Visual Studio Express C++ tools (it is a c++ class, in
fact.) They will need to generate some kind of file that can be read
by the C-Spy debugger that is part of the IAR Kickstart IDE and loaded
into the eZ430-F2013 tool.

I just looked around a little, tonight, and noted what I expected to
see -- that the .D43 format appears to be in a custom, binary format.
So, although that would be expecting a lot for the students to attempt
to produce, I decided to see if there was clear documentation on the
.D43 format and didn't find anything, tonight.

I am now tentatively holding the opinion that it isn't documented,
purposefully. That being the tentatively assumed case, I then looked
at the option of generating other output formats and found that to be
pretty easy to do in the IAR Kickstart. But then trying to get the
C-Spy program to download code into the FET tool using one of those
file formats (appears I can generate up to two different formats at
once) seems to have failed. Reading more documentation, I
consistently find comments about C-Spy using .D43 files and
consistently cannot find comments about C-Spy using any other format
in loading compiled/assembled code into the FET tool the students will
have.

I tried enabling the "Allow C-Spy-specific extra output file" option,
which when checked, allows the next tab "Extra Output" to be modified.
The idea being that just maybe, on some off chance, the C-Spy debugger
might instead choose to read the MSP430-text file I selected to be
generated, instead of the .D43 file that was generated along with it.
But the message comes up:

Loaded debugee: C:\MSP430\CS161\Debug\Exe\Project 10.d43

So it still uses the .D43 file, when present. I also tried clicking
"Other" on the Output tab, instead of "Debug information for C-Spy",
which stops the production of the .D43 file, entirely. But then the
C-Spy program complains.

Basically, the students should not have their projects expanded too
much. They need to write a simple assembler, including parsing,
anding and ioring bits. They __may__ (and this isn't decided yet)
still be writing a simulator of their own -- however, it's still
important, the teacher and I both think, for the students to be able
to also see their generated code running on a real piece of hardware
with a professional-scale debugger tools to help them see how to
visualize more comprehensively. So even if they do write their own
simulator (and that isn't for sure, yet), and can support their own
data format, I think it remains important to find a way to pass along
the binary code they generate to an actual piece of hardware -- the
FET tool -- and to use the IAR Kickstart + C-Spy tools as an adjunct
to the entire class process.

I'm open to suggestions about this. Right now, I don't see the clear
path. Looks like C-Spy uses only .D43 and that .D43 is proprietary
(to me, tonight.) This being the case, I'm open to the idea of other
tools. Bear in mind, though, that these students are, at best,
familiar with WindowsXP and the Microsoft Visual Studio Express and
console applications. They do NOT know how to use Linux and that is
NOT a part of the course, nor will it be. Whatever is used, must be
easily used as part of the WindowsXP systems they already use. Can't
change too much of the course, right now.

Thanks in advance,
Jon Start a New Thread

You should be able to create an empty project in IAR
debugger and add only the hex file to it.
When you click on the debug icon the debugger will
launch and download that file. Let me know if this
works. I've done this number of time.
I've myself experience the frustration of going from
.d43 -> hex and vice versa.
It would have been nice of IAR to have a utility to
convert files into various formats. New IAR tools do
not accept .d43 files created by really old tools.
Hex file is a way to go to ensure compatibility. When
you create a .d43 file you have to make sure that you
have second output option checked to create a hex
file.

-Sumukh

--- Jon Kirwan wrote:

> I was just asked by a local college prof about the
> idea of modifying
> his CS162 course (a winter term, coming up) to use
> the MSP430
> processor. His students need to write a simple
> assembler tool of
> their own, as one of two class projects they must
> do, and it needs to
> generate binary code that can be simulated. (The
> second project is,
> in fact, the simulator.) He is thinking about the
> idea of having them
> do a small subset of the MSP430 instructions and, if
> possible, taking
> their own assembler outputs and loading them into an
> actual MSP430 on
> their own eZ430-F2013 development tools (lab fee
> used to buy those.)
>
> The problem here is that the students are writing
> their own assembler
> and generating their own binary code result, using
> masking and ioring
> of bits (which is part of their learning
> experience.) This code sits
> in an array in a C++ program they write on the IBM
> PC using the
> Microsoft Visual Studio Express C++ tools (it is a
> c++ class, in
> fact.) They will need to generate some kind of file
> that can be read
> by the C-Spy debugger that is part of the IAR
> Kickstart IDE and loaded
> into the eZ430-F2013 tool.
>
> I just looked around a little, tonight, and noted
> what I expected to
> see -- that the .D43 format appears to be in a
> custom, binary format.
> So, although that would be expecting a lot for the
> students to attempt
> to produce, I decided to see if there was clear
> documentation on the
> .D43 format and didn't find anything, tonight.
>
> I am now tentatively holding the opinion that it
> isn't documented,
> purposefully. That being the tentatively assumed
> case, I then looked
> at the option of generating other output formats and
> found that to be
> pretty easy to do in the IAR Kickstart. But then
> trying to get the
> C-Spy program to download code into the FET tool
> using one of those
> file formats (appears I can generate up to two
> different formats at
> once) seems to have failed. Reading more
> documentation, I
> consistently find comments about C-Spy using .D43
> files and
> consistently cannot find comments about C-Spy using
> any other format
> in loading compiled/assembled code into the FET tool
> the students will
> have.
>
> I tried enabling the "Allow C-Spy-specific extra
> output file" option,
> which when checked, allows the next tab "Extra
> Output" to be modified.
> The idea being that just maybe, on some off chance,
> the C-Spy debugger
> might instead choose to read the MSP430-text file I
> selected to be
> generated, instead of the .D43 file that was
> generated along with it.
> But the message comes up:
>
> Loaded debugee: C:\MSP430\CS161\Debug\Exe\Project
> 10.d43
>
> So it still uses the .D43 file, when present. I
> also tried clicking
> "Other" on the Output tab, instead of "Debug
> information for C-Spy",
> which stops the production of the .D43 file,
> entirely. But then the
> C-Spy program complains.
>
> Basically, the students should not have their
> projects expanded too
> much. They need to write a simple assembler,
> including parsing,
> anding and ioring bits. They __may__ (and this
> isn't decided yet)
> still be writing a simulator of their own --
> however, it's still
> important, the teacher and I both think, for the
> students to be able
> to also see their generated code running on a real
> piece of hardware
> with a professional-scale debugger tools to help
> them see how to
> visualize more comprehensively. So even if they do
> write their own
> simulator (and that isn't for sure, yet), and can
> support their own
> data format, I think it remains important to find a
> way to pass along
> the binary code they generate to an actual piece of
> hardware -- the
> FET tool -- and to use the IAR Kickstart + C-Spy
> tools as an adjunct
> to the entire class process.
>
> I'm open to suggestions about this. Right now, I
> don't see the clear
> path. Looks like C-Spy uses only .D43 and that .D43
> is proprietary
> (to me, tonight.) This being the case, I'm open to
> the idea of other
> tools. Bear in mind, though, that these students
> are, at best,
> familiar with WindowsXP and the Microsoft Visual
> Studio Express and
> console applications. They do NOT know how to use
> Linux and that is
> NOT a part of the course, nor will it be. Whatever
> is used, must be
> easily used as part of the WindowsXP systems they
> already use. Can't
> change too much of the course, right now.
>
> Thanks in advance,
> Jon
>
********************************
Sumukh Pathare
Email: s...@ieee.org
Phone: 781-856-2054
******************************** Start a New Thread

I highly recommend the free/evaluation version of FET-Pro430 from
Elprotronic Inc.

KISS - Keep It Simple and Stupid. It only read/erase/write Flash in
MSP430F chips and nothing else. Any USB, Parallel Port, COM Port
tools, and either 4-wire or 2-wire JTAG, can be used. The file format
to read/store from/to PC is the so called TI Hex Format.

--- In m..., Jon Kirwan wrote:
>
> I was just asked by a local college prof about the idea of modifying
> his CS162 course (a winter term, coming up) to use the MSP430
> processor. His students need to write a simple assembler tool of
> their own, as one of two class projects they must do, and it needs to
> generate binary code that can be simulated. (The second project is,
> in fact, the simulator.) He is thinking about the idea of having them
> do a small subset of the MSP430 instructions and, if possible, taking
> their own assembler outputs and loading them into an actual MSP430 on
> their own eZ430-F2013 development tools (lab fee used to buy those.)
>
> The problem here is that the students are writing their own assembler
> and generating their own binary code result, using masking and ioring
> of bits (which is part of their learning experience.) This code sits
> in an array in a C++ program they write on the IBM PC using the
> Microsoft Visual Studio Express C++ tools (it is a c++ class, in
> fact.) They will need to generate some kind of file that can be read
> by the C-Spy debugger that is part of the IAR Kickstart IDE and loaded
> into the eZ430-F2013 tool.
>
> I just looked around a little, tonight, and noted what I expected to
> see -- that the .D43 format appears to be in a custom, binary format.
> So, although that would be expecting a lot for the students to attempt
> to produce, I decided to see if there was clear documentation on the
> .D43 format and didn't find anything, tonight.
>
> I am now tentatively holding the opinion that it isn't documented,
> purposefully. That being the tentatively assumed case, I then looked
> at the option of generating other output formats and found that to be
> pretty easy to do in the IAR Kickstart. But then trying to get the
> C-Spy program to download code into the FET tool using one of those
> file formats (appears I can generate up to two different formats at
> once) seems to have failed. Reading more documentation, I
> consistently find comments about C-Spy using .D43 files and
> consistently cannot find comments about C-Spy using any other format
> in loading compiled/assembled code into the FET tool the students will
> have.
>
> I tried enabling the "Allow C-Spy-specific extra output file" option,
> which when checked, allows the next tab "Extra Output" to be modified.
> The idea being that just maybe, on some off chance, the C-Spy debugger
> might instead choose to read the MSP430-text file I selected to be
> generated, instead of the .D43 file that was generated along with it.
> But the message comes up:
>
> Loaded debugee: C:\MSP430\CS161\Debug\Exe\Project 10.d43
>
> So it still uses the .D43 file, when present. I also tried clicking
> "Other" on the Output tab, instead of "Debug information for C-Spy",
> which stops the production of the .D43 file, entirely. But then the
> C-Spy program complains.
>
> Basically, the students should not have their projects expanded too
> much. They need to write a simple assembler, including parsing,
> anding and ioring bits. They __may__ (and this isn't decided yet)
> still be writing a simulator of their own -- however, it's still
> important, the teacher and I both think, for the students to be able
> to also see their generated code running on a real piece of hardware
> with a professional-scale debugger tools to help them see how to
> visualize more comprehensively. So even if they do write their own
> simulator (and that isn't for sure, yet), and can support their own
> data format, I think it remains important to find a way to pass along
> the binary code they generate to an actual piece of hardware -- the
> FET tool -- and to use the IAR Kickstart + C-Spy tools as an adjunct
> to the entire class process.
>
> I'm open to suggestions about this. Right now, I don't see the clear
> path. Looks like C-Spy uses only .D43 and that .D43 is proprietary
> (to me, tonight.) This being the case, I'm open to the idea of other
> tools. Bear in mind, though, that these students are, at best,
> familiar with WindowsXP and the Microsoft Visual Studio Express and
> console applications. They do NOT know how to use Linux and that is
> NOT a part of the course, nor will it be. Whatever is used, must be
> easily used as part of the WindowsXP systems they already use. Can't
> change too much of the course, right now.
>
> Thanks in advance,
> Jon
> Start a New Thread

I see the "We offer FET-Pro430 Lite version FREE." I will look over
the pages and see what that offers for the class. However, let me add
a caveat about this.

The class is a C++ class. That's what it is about. In preparation
for further education for a CS degree, the students are getting a
leg-up (boost) by having to do some parsing and learning assembly
language and machine coding. But C++ remains their "main tool" for
learning, at this state of things. They are just getting a light
exposure to a more detailed understanding of things. One of the nice
aspects of the IAR Kickstart IDE is that it includes a C++ compiler,
limited to 4k but that is perfect for these students. They don't need
more than that -- especially with the F2013 in the eZ430 FET device.

So part of the advantage for the IAR Kickstart IDE is that they only
have to invest their limited education time into one IDE, they get a
C++ compiler to play with on their own time (or perhaps as part of a
class yet to be developed) with some freely provided educational C++
programs I've already written as part of a self-directed tutorial, and
they also get the debugger, assembler, and so on. So the better
solution would be to make the C-Spy do what's needed for this class
and let the rest simply flow out of that experience.

Adding another tool to the chain may be okay. I'm going to play with
it and see how it can be fitted into the overall thrust of things. So
thanks VERY much for the suggestion. I will put some time into it. I
am also interested, though, in any other answers as well. So perhaps
there are other options for me to consider, as well. But maybe this
is a quite satisfying solution, too. So, thanks again for suggesting
it.

Jon

On Sun, 21 Oct 2007 16:19:04 -0000, you wrote:

>I highly recommend the free/evaluation version of FET-Pro430 from
>Elprotronic Inc.
>
>KISS - Keep It Simple and Stupid. It only read/erase/write Flash in
>MSP430F chips and nothing else. Any USB, Parallel Port, COM Port
>tools, and either 4-wire or 2-wire JTAG, can be used. The file format
>to read/store from/to PC is the so called TI Hex Format.
>
>--- In m..., Jon Kirwan wrote:
>>
>> I was just asked by a local college prof about the idea of modifying
>> his CS162 course (a winter term, coming up) to use the MSP430
>> processor. His students need to write a simple assembler tool of
>> their own, as one of two class projects they must do, and it needs to
>> generate binary code that can be simulated. (The second project is,
>> in fact, the simulator.) He is thinking about the idea of having them
>> do a small subset of the MSP430 instructions and, if possible, taking
>> their own assembler outputs and loading them into an actual MSP430 on
>> their own eZ430-F2013 development tools (lab fee used to buy those.)
>>
>> The problem here is that the students are writing their own assembler
>> and generating their own binary code result, using masking and ioring
>> of bits (which is part of their learning experience.) This code sits
>> in an array in a C++ program they write on the IBM PC using the
>> Microsoft Visual Studio Express C++ tools (it is a c++ class, in
>> fact.) They will need to generate some kind of file that can be read
>> by the C-Spy debugger that is part of the IAR Kickstart IDE and loaded
>> into the eZ430-F2013 tool.
>>
>> I just looked around a little, tonight, and noted what I expected to
>> see -- that the .D43 format appears to be in a custom, binary format.
>> So, although that would be expecting a lot for the students to attempt
>> to produce, I decided to see if there was clear documentation on the
>> .D43 format and didn't find anything, tonight.
>>
>> I am now tentatively holding the opinion that it isn't documented,
>> purposefully. That being the tentatively assumed case, I then looked
>> at the option of generating other output formats and found that to be
>> pretty easy to do in the IAR Kickstart. But then trying to get the
>> C-Spy program to download code into the FET tool using one of those
>> file formats (appears I can generate up to two different formats at
>> once) seems to have failed. Reading more documentation, I
>> consistently find comments about C-Spy using .D43 files and
>> consistently cannot find comments about C-Spy using any other format
>> in loading compiled/assembled code into the FET tool the students will
>> have.
>>
>> I tried enabling the "Allow C-Spy-specific extra output file" option,
>> which when checked, allows the next tab "Extra Output" to be modified.
>> The idea being that just maybe, on some off chance, the C-Spy debugger
>> might instead choose to read the MSP430-text file I selected to be
>> generated, instead of the .D43 file that was generated along with it.
>> But the message comes up:
>>
>> Loaded debugee: C:\MSP430\CS161\Debug\Exe\Project 10.d43
>>
>> So it still uses the .D43 file, when present. I also tried clicking
>> "Other" on the Output tab, instead of "Debug information for C-Spy",
>> which stops the production of the .D43 file, entirely. But then the
>> C-Spy program complains.
>>
>> Basically, the students should not have their projects expanded too
>> much. They need to write a simple assembler, including parsing,
>> anding and ioring bits. They __may__ (and this isn't decided yet)
>> still be writing a simulator of their own -- however, it's still
>> important, the teacher and I both think, for the students to be able
>> to also see their generated code running on a real piece of hardware
>> with a professional-scale debugger tools to help them see how to
>> visualize more comprehensively. So even if they do write their own
>> simulator (and that isn't for sure, yet), and can support their own
>> data format, I think it remains important to find a way to pass along
>> the binary code they generate to an actual piece of hardware -- the
>> FET tool -- and to use the IAR Kickstart + C-Spy tools as an adjunct
>> to the entire class process.
>>
>> I'm open to suggestions about this. Right now, I don't see the clear
>> path. Looks like C-Spy uses only .D43 and that .D43 is proprietary
>> (to me, tonight.) This being the case, I'm open to the idea of other
>> tools. Bear in mind, though, that these students are, at best,
>> familiar with WindowsXP and the Microsoft Visual Studio Express and
>> console applications. They do NOT know how to use Linux and that is
>> NOT a part of the course, nor will it be. Whatever is used, must be
>> easily used as part of the WindowsXP systems they already use. Can't
>> change too much of the course, right now.
>>
>> Thanks in advance,
>> Jon Start a New Thread

On Sun, 21 Oct 2007 12:20:17 -0700, I wrote to old_cow_yellow:

>I see the "We offer FET-Pro430 Lite version FREE." I will look over
>the pages and see what that offers for the class.

Looks decent enough. We may be able to use it. It does leave me with
at least one problem, though:

If the students write their own assembler tool and are able to
generate MSP430-Text files that can be read and programmed into the
eZ430 tool using the FET-Pro430 Lite software, this still leaves them
with the single-step debugging problem. They need to still use the
IAR Kickstart IDE's C-Spy program for that. It's not enough to just
"load and go." If there is a bug, and there most certainly will be a
lot of them in a class of neophyte students writing assemblers, then
they need to see what they actually generated listed out as
disassembled instructions. And they may even want to single step
through their code. They won't need symbolics, though. Just the
straight disassembled assembly with address values listed. To do
this, they will need to enter C-Spy without the production of any .D43
file. C-Spy will have to "go it, cold," so to speak.

I tried this out by telling C-Spy to "suppress download" and to see if
it can attach itself to an existing programmed device. To keep this
simple and quick, I used an existing project which was also in C++ but
was NOT the actual code I'd loaded into the device. It did NOT burn
the project into the device, luckily, and instead just attached to the
existing application loaded into it. However,

(1) The IAR C++ compiler appears to add debug_break code -- something
I need to check out and see if this will be a problem in attaching to
existing flash code downloaded by FET-Pro430 software. They will
definitely NOT be writing any code to support a debug break from
C-Spy, if C-Spy expects anything like that. I haven't been using
C-Spy this way, so I'm learning as I go here. But this could be an
issue. Maybe not.

(2) The obvious chain of instructions for a student, after specifying
the file to use, would be to press the "Erase Flash" button, then the
"Blank Check" button, then the "Write Flash" button, then the "Verify
Flash" button, before doing the Reset to see if it runs okay. However,
I just checked and the "Erase Flash" completely destroys the
calibration data loaded into the device by TI. This, in fact, is VERY
BAD. I will either need to develop a procedure for the students to
follow that includes capturing that information first (complicating
their lives) or else read the documentation further to see if there is
another way around this issue.

Jon Start a New Thread

On Sun, 21 Oct 2007 13:47:17 -0700, I wrote:

>(2) The obvious chain of instructions for a student, after specifying
>the file to use, would be to press the "Erase Flash" button, then the
>"Blank Check" button, then the "Write Flash" button, then the "Verify
>Flash" button, before doing the Reset to see if it runs okay. However,
>I just checked and the "Erase Flash" completely destroys the
>calibration data loaded into the device by TI. This, in fact, is VERY
>BAD. I will either need to develop a procedure for the students to
>follow that includes capturing that information first (complicating
>their lives) or else read the documentation further to see if there is
>another way around this issue.

Okay. I found documentation on the FET-Pro430-Lite software that
tells me how to avoid destroying the contents of the calibration data
loaded into the F2013 by TI. It's all there, so that is good. That
problem is resolved.

Jon Start a New Thread

--- In m..., Jon Kirwan wrote:
>
> ...So part of the advantage for the IAR Kickstart IDE is that they
only
> have to invest their limited education time into one IDE, they get a
> C++ compiler to play with on their own time (or perhaps as part of a
> class yet to be developed) with some freely provided educational C++
> programs I've already written as part of a self-directed tutorial, and
> they also get the debugger, assembler, and so on. So the better
> solution would be to make the C-Spy do what's needed for this class
> and let the rest simply flow out of that experience.
>
> Adding another tool to the chain may be okay. ...

Another approach may be to have you (or one of the more advanced
students) write a C program for the ez430 that takes a "C" data array
and flashes it and then jumps to (or calls) it. Then the student's
assembler job becomes one of writing an output format that is a "C"
include file with a format you can define. To run the student's
program he/she would compile an instance of the program you provide
with the include file that is produced by the assembler.

You might not have full features of the processor available, but I get
the idea that you are not expecting very sophisticated programs, just
something that demonstrates assembler correctness.

This solution may well violate old yellow cow's KISS maxim but, if done
right, could keep the complexity out of the students way.

Regards,
Bryon Wiscons Start a New Thread

On Sun, 21 Oct 2007 23:26:42 -0000, you wrote:

>--- In m..., Jon Kirwan wrote:
>>
>> If the students write their own assembler tool and are able to
>> generate MSP430-Text files that can be read and programmed into
>> the eZ430 tool using the FET-Pro430 Lite software, this still
>> leaves them with the single-step debugging problem. They need
>> to still use the IAR Kickstart IDE's C-Spy program for that.
>
>*** Yes, and they can do that.
>
>> And they may even want to single step through their code. They
>> won't need symbolics, though. Just the straight disassembled
>> assembly with address values listed. To do this, they will need
>> to enter C-Spy without the production of any .D43 file. C-Spy
>> will have to "go it, cold," so to speak.
>
>*** Yes, and they can do that.
>
>> I tried this out by telling C-Spy to "suppress download" and to
>> see if it can attach itself to an existing programmed device.
>
>*** Yes, that is correct.
>
>> To keep this simple and quick, I used an existing project which
>> was also in C++ but was NOT the actual code I'd loaded into the
>> device. It did NOT burn the project into the device, luckily,
>> and instead just attached to the existing application loaded
>> into it.
>
>*** No, you should have created a dummy assembly project with no
>symbols and no start-up code. Tell C-Spy to suppress download.
>Go to debug, now you can single step, set break point, etc.

Was getting to that point, but I've been investigating other aspects
tonight. For example, I tracked down the documentation on the TI-TXT
format in SLAU101H.PDF on TI's site. It's important to have some
formal specifications for the ASCII output file the students will
produce.

Now, the gap is closing quite a bit. With IAR Kickstart to provide a
C++ compiler and assembler and debugger, and with FET-Pro430 lite to
enable ASCII file input in TI-TXT format for burning the flash with
the code, and documentation on the TI-TXT format, and the ability to
use a project to tell C-Spy to avoid downloading code but to just go
to the existing code, I think I'm pretty close.

I still would like to know if anyone knowledgeable on C-Spy can tell
me if it can do the download, itself, from an ASCII file input format
that is documented. But it's not necessary that I know, just
something I'd like to nail down, finally.

Next step is to actually write the assembler, myself, tonight. Need
to see just how much complexity is in the resulting code and whether
or not it is too much to teach. (Last year's class used a
hypothetical machine with a VERY SIMPLE assembly source format --
nothing like the addressing mode syntax in the MSP430.) So, other
problems pushed aside for now, this will be the telling difference.

Thanks,
Jon Start a New Thread

--- In m..., Jon Kirwan wrote:
>
> I still would like to know if anyone knowledgeable on C-Spy
> can tell me if it can do the download, itself, from an ASCII
> file input format that is documented. But it's not necessary
> that I know, just something I'd like to nail down, finally.
>

*** According to "MSP430 IAR Embedded Workbench IDE User Guide"
(Fifth exition: March 2006) page 8:
"UBROF, Intel-extended, and Motorola input formats supported."
(This is about "Additional general C-SPY Debugger features")

Note that KickStart includes many components. Each component
has its own version number. There are also many user guides.
Each user guide also has its own version number. I am not sure
if the above applies to the KickStart kit you get. IAR just
released a new version. That new version is not in KickStart
yet. Start a New Thread

On Mon, 22 Oct 2007 17:59:28 -0000, old_cow_yellow wrote:

>--- In m..., Jon Kirwan wrote:
>>
>> I still would like to know if anyone knowledgeable on C-Spy
>> can tell me if it can do the download, itself, from an ASCII
>> file input format that is documented. But it's not necessary
>> that I know, just something I'd like to nail down, finally.
>>*** According to "MSP430 IAR Embedded Workbench IDE User Guide"
>(Fifth exition: March 2006) page 8:
>"UBROF, Intel-extended, and Motorola input formats supported."
>(This is about "Additional general C-SPY Debugger features")
>
>Note that KickStart includes many components. Each component
>has its own version number. There are also many user guides.
>Each user guide also has its own version number. I am not sure
>if the above applies to the KickStart kit you get. IAR just
>released a new version. That new version is not in KickStart
>yet.

Thanks for the quote. However, I'm still not sure how to get it to
actually __read__ these supposedly supported "input formats." I can
easily get the linker tool to generate them. But your discovery
doesn't tell me how to specify a text formatted file for input to
C-Spy -- though it certainly seems to suggest the possibility.

So I went looking, based upon your prod above. What I find is the
following section:

==================================================================Executable files built outside of the Embedded Workbench
--------------------

It is also possible to load C-SPY with a project that was built
outside the Embedded Workbench, for example projects built on the
command line. To be able to set C-SPY options for the externally
built project, you must create a project within the Embedded
Workbench.

To load an externally built executable file, you must first create a
project for it in your workspace. Choose Project>Create New Project,
and specify a project name. To add the executable file to the project,
choose Project>Add Files and make sure to choose All Files in the
Files of type drop-down list. Locate the executable file (filename
extension d43). To start the executable file, select the project in
the Workspace window and click the Debug button. The project can be
reused whenever you rebuild your executable file.

The only project options that are meaningful to set for this kind of
project are options in the General Options and Debugger categories.
Make sure to set up the general project options in the same way as
when the executable file was built.
==================================================================
I tried, in the above, to include fuller context. As you can see
there, they specifically mention that you need to add the executable
file to the project and specifically mention the D43 extension. They
do NOT, anywhere there, talk about specifying other file types.

I have yet to attempt to do that with a file having a different
extension. So it's possible that although the above discussion
doesn't say so, I may be able to add a text filetype to the project
and it may be the case that C-Spy will recognize it and use it. But
the above text certainly does NOT give me confidence that it will. I
am at a different place, right now, but I will try it soon -- today.

I also took a look at the C-Spy Debugger Reference in the back of that
guide you mentioned, just to see if I could find something relevant. I
didn't find anything, yet. I also need to see if I can load memory
from a file, using a mouse right-click thing. I think I am able to
save memory... so it may be the case that I could load it into flash,
too. Though, considering that it may need erasure beforehand, maybe
not. That may only work with ram, if it works at all. I'll have to
see.

Thanks for trying to help,
Jon Start a New Thread