Reply by John Porubek April 24, 20122012-04-24
On Tue, Apr 24, 2012 at 4:59 AM, chang luke wrote:
> I've suffer from this too.
> I've designed my own assembler/disassembler/decompiler/...even compiler under win32forth.
> I almost completd everything and got into the test pace. It stucked me from loading the .hex file into the IAR for burning. It has no problem for 4k or less, but not for larger size.
> Can anyone suggest method to cope with this? tks!

There are several approaches to downloading hex files to MSP430s. The
one I'm most familiar with is MSPDebug
(http://mspdebug.sourceforge.net), which I mentioned in my previous
posts. However, there's also Elprotronic's FET-Pro430 Lite
(http://www.elprotronic.com/fetpro430.html), which is free. TI also
offers a free tool, their MSP430 Flasher
(http://processors.wiki.ti.com/index.php/MSP430_Flasher_-_Command_Line_Programmer).
Hope that helps.

Beginning Microcontrollers with the MSP430

Reply by John Porubek April 24, 20122012-04-24
On Tue, Apr 24, 2012 at 2:20 AM, old_cow_yellow
wrote:
> I heard about that too. There is even a work around. See:
> http://www.forth-ev.de/article.php/20120315005609790
>
> However, I have not seen this limitation. As long as I use assembly only, I see no size limit.
>
> I think the latest KickStart download is called SLAC090ah.zip. After unzip it, you get FET_R611.exe. When installed, it says Release 5.40.6
>
> I normally use an older version. Download file is called SLAC090aa.zip. After unzip, FET_R604.exe. Release 5.20.4. I use this earlier release because the Disassembler window can be copied to the Clipboard and past in Noteped. Later releases cannot do this.

Thanks for the responses, Blakely and OCY. That's how I've been using
IAR Kickstart, too. I'm running it mostly using Wine on Linux, then I
download and debug using MSPDebug. BTW, MSPDebug is fairly easy to get
running under Windows also, using the mingw32 builds provided by
Matthias Hartmann (thanks Matthias!). On this occasion, I thought I'd
use the more integrated and visual debugging environment offered by
IAR on Windows. No such luck.

Thanks also, OCY, for the Kickstart version info. I'm using FET_R610.
Good to know what version I have to go back to in order to regain the
Disassembler window copying functionality.

The following is a little off-topic, but please bear with me. I had to
chuckle a bit when clicking on the link OCY provided. It seems like
I've been spending a lot of time recently testing my memory of long
past high-school and college German language classes. A while ago I
stumbled on a reference to a version of Forth for the MSP430 called
Mecrisp (http://mecrisp.sourceforge.net/), with a version that runs on
the MSP430G2553 on a LaunchPad. All of the source code is in German,
but Matthias Koch, Mecrisp's creator, has been very helpful in
translating things for me and helping me understand how this slightly
unusual Forth works. But I've also found that Google Translate can be
a very useful tool!

The program I was trying to debug, that started off this thread, was
my port of CamelForth430 to the G2553. CamelForth is a more
traditional Forth than Mecrisp. Then yesterday, Dirk Bruehl posted a
link in this forum to an already existing port of CamelForth430 to the
G2553 running on a LaunchPad - 4E4th
(http://www.somersetweb.com/4E4th/EN.html), which is also natively
German! Fortunately for me, most of the material is available in
English. So I'll probably cease my porting efforts and swing my
support to 4E4th (and Mecrisp). In any event, it seems that German is
going to be in my thoughts for the foreseeable future!
Reply by chang luke April 24, 20122012-04-24
I've suffer from this too. 
I've designed my own assembler/disassembler/decompiler/...even compiler under win32forth.
I almost completd everything and got into the test pace. It stucked me from loading the .hex file into the IAR for burning. It has no problem for 4k or less, but not for larger size.
   Can anyone suggest method to cope with this?   tks!

--- 12/4/24 (二),old_cow_yellow 寫道:
寄件者: old_cow_yellow
主旨: [msp430] Re: Has IAR Kickstart code size limitation changed?
收件者: m...
日期: 2012年4月24日,二,下午2:20

 

I heard about that too. There is even a work around. See:
http://www.forth-ev.de/article.php/20120315005609790

However, I have not seen this limitation. As long as I use assembly only, I see no size limit.

I think the latest KickStart download is called SLAC090ah.zip. After unzip it, you get FET_R611.exe. When installed, it says Release 5.40.6

I normally use an older version. Download file is called SLAC090aa.zip. After unzip, FET_R604.exe. Release 5.20.4. I use this earlier release because the Disassembler window can be copied to the Clipboard and past in Noteped. Later releases cannot do this.

--- In m..., John Porubek wrote:
>
> I have a program written in assembler that compiles OK within IAR
> Kickstart to about 6700 bytes. When I go to download this into a G2553
> chip, I get an error message that says: "User error: Your application
> is too large. This version of IAR Embedded Workbench has a code
> limitation of 4096 bytes." In the past, I have downloaded other
> versions of this program into an F169 chip and an F2274 chip in the
> EZ43-RF2500 using earlier versions of Kickstart.
>
> I have read, in this forum and elsewhere, that there are no code-size
> limitations for assembler code in Kickstart. And, as I mentioned, my
> code DOES compile. Has IAR changed it's policy to move size checking
> to the debugger interface (I get the same error message if I target
> the simulator)?
>
> I've been using MSPDebug for most of my downloading, so it's possible
> this change occurred several versions ago of the IAR tools.
>



Reply by old_cow_yellow April 24, 20122012-04-24
I heard about that too. There is even a work around. See:
http://www.forth-ev.de/article.php/20120315005609790

However, I have not seen this limitation. As long as I use assembly only, I see no size limit.

I think the latest KickStart download is called SLAC090ah.zip. After unzip it, you get FET_R611.exe. When installed, it says Release 5.40.6

I normally use an older version. Download file is called SLAC090aa.zip. After unzip, FET_R604.exe. Release 5.20.4. I use this earlier release because the Disassembler window can be copied to the Clipboard and past in Noteped. Later releases cannot do this.

--- In m..., John Porubek wrote:
>
> I have a program written in assembler that compiles OK within IAR
> Kickstart to about 6700 bytes. When I go to download this into a G2553
> chip, I get an error message that says: "User error: Your application
> is too large. This version of IAR Embedded Workbench has a code
> limitation of 4096 bytes." In the past, I have downloaded other
> versions of this program into an F169 chip and an F2274 chip in the
> EZ43-RF2500 using earlier versions of Kickstart.
>
> I have read, in this forum and elsewhere, that there are no code-size
> limitations for assembler code in Kickstart. And, as I mentioned, my
> code DOES compile. Has IAR changed it's policy to move size checking
> to the debugger interface (I get the same error message if I target
> the simulator)?
>
> I've been using MSPDebug for most of my downloading, so it's possible
> this change occurred several versions ago of the IAR tools.
>

Reply by John Porubek April 23, 20122012-04-23
I have a program written in assembler that compiles OK within IAR
Kickstart to about 6700 bytes. When I go to download this into a G2553
chip, I get an error message that says: "User error: Your application
is too large. This version of IAR Embedded Workbench has a code
limitation of 4096 bytes." In the past, I have downloaded other
versions of this program into an F169 chip and an F2274 chip in the
EZ43-RF2500 using earlier versions of Kickstart.

I have read, in this forum and elsewhere, that there are no code-size
limitations for assembler code in Kickstart. And, as I mentioned, my
code DOES compile. Has IAR changed it's policy to move size checking
to the debugger interface (I get the same error message if I target
the simulator)?

I've been using MSPDebug for most of my downloading, so it's possible
this change occurred several versions ago of the IAR tools.