Background:
- using MSP430F122
- using IAR kickstart

I'm trying to implement a circular buffer somewhat similar to IAR appnote 430-03. However my buffer needs to be substantially larger. Even though I have plenty of space (program is about 3.5K), the IAR compiler balks with message:
----------------
Error[e16]: Segment CSTACK (size: 0x50 align: 0x1) is too long for segment definition. At least 0x13 more bytes needed. The problem occurred while processing the segment placement command
"-Z(DATA)CSTACK+_STACK_SIZE#", where at the moment of placement the available memory ranges were "CODE:2C3-300"
Reserved ranges relevant to this placement:
CODE:200-203 DATA16_I
CODE:204-2C2 DATA16_Z
-------------

My buffers are declared at top of file:

unsigned char queueType[64];
unsigned char queueData[64];

Anyone know how I can make these buffers larger?

TIA.

Start a New Thread

Looking at your data types and looking at the specs for the F122, I don't think you can make the buffer much larger than you have it. The processor only has 256 bytes of RAM and those two buffers occupy half of it.

In short, you've run out of RAM. A google search on DATA16_Z shows quite a number of people having similar problems as you.

-Steve

-----Original Message-----
From: m... [mailto:m...] On Behalf Of baxtercodeworks
Sent: Thursday, December 02, 2010 1:05 PM
To: m...
Subject: [msp430] Buffer Problem

Background:
- using MSP430F122
- using IAR kickstart

I'm trying to implement a circular buffer somewhat similar to IAR appnote 430-03. However my buffer needs to be substantially larger. Even though I have plenty of space (program is about 3.5K), the IAR compiler balks with message:
----------------
Error[e16]: Segment CSTACK (size: 0x50 align: 0x1) is too long for segment definition. At least 0x13 more bytes needed. The problem occurred while processing the segment placement command
"-Z(DATA)CSTACK+_STACK_SIZE#", where at the moment of placement the available memory ranges were "CODE:2C3-300"
Reserved ranges relevant to this placement:
CODE:200-203 DATA16_I
CODE:204-2C2 DATA16_Z
-------------

My buffers are declared at top of file:

unsigned char queueType[64];
unsigned char queueData[64];

Anyone know how I can make these buffers larger?

TIA.

Start a New Thread

I've got a similar program that runs on the MSP430F1121a - which has only 128 bytes ram, and it can handle a slightly larger buffer. I've tried eliminating variables (consts, statics, locals, etc.) sometimes gaining a little, but mostly without gaining anything.

I do have a command table that is currently const, that could possibly go into Flash memory, but I'm unsure how to do that given that I'm already putting some data there using '__root const ... '.

--- In m..., "Hayashi, Steve" wrote:
>
> Looking at your data types and looking at the specs for the F122, I don't think you can make the buffer much larger than you have it. The processor only has 256 bytes of RAM and those two buffers occupy half of it.
>
> In short, you've run out of RAM. A google search on DATA16_Z shows quite a number of people having similar problems as you.
>
> -Steve
>
> -----Original Message-----
> From: m... [mailto:m...] On Behalf Of baxtercodeworks
> Sent: Thursday, December 02, 2010 1:05 PM
> To: m...
> Subject: [msp430] Buffer Problem
>
> Background:
> - using MSP430F122
> - using IAR kickstart
>
> I'm trying to implement a circular buffer somewhat similar to IAR appnote 430-03. However my buffer needs to be substantially larger. Even though I have plenty of space (program is about 3.5K), the IAR compiler balks with message:
> ----------------
> Error[e16]: Segment CSTACK (size: 0x50 align: 0x1) is too long for segment definition. At least 0x13 more bytes needed. The problem occurred while processing the segment placement command
> "-Z(DATA)CSTACK+_STACK_SIZE#", where at the moment of placement the available memory ranges were "CODE:2C3-300"
> Reserved ranges relevant to this placement:
> CODE:200-203 DATA16_I
> CODE:204-2C2 DATA16_Z
> -------------
>
> My buffers are declared at top of file:
>
> unsigned char queueType[64];
> unsigned char queueData[64];
>
> Anyone know how I can make these buffers larger?
>
> TIA.
>
> Start a New Thread

Pursuant to other research, I'm looking at lnk430F122.xcl and I find that -D_HEAP_SIZEP. I'm not doing any mallocs, can I grab some of the heap for my buffers? If so, do I just set -D_HEAP_SIZE smaller, or do I need to do more?

--- In m..., "baxtercodeworks" wrote:
>
> I've got a similar program that runs on the MSP430F1121a - which has only 128 bytes ram, and it can handle a slightly larger buffer. I've tried eliminating variables (consts, statics, locals, etc.) sometimes gaining a little, but mostly without gaining anything.
>
> I do have a command table that is currently const, that could possibly go into Flash memory, but I'm unsure how to do that given that I'm already putting some data there using '__root const ... '.
>
> --- In m..., "Hayashi, Steve" wrote:
> >
> > Looking at your data types and looking at the specs for the F122, I don't think you can make the buffer much larger than you have it. The processor only has 256 bytes of RAM and those two buffers occupy half of it.
> >
> > In short, you've run out of RAM. A google search on DATA16_Z shows quite a number of people having similar problems as you.
> >
> > -Steve
> >
> > -----Original Message-----
> > From: m... [mailto:m...] On Behalf Of baxtercodeworks
> > Sent: Thursday, December 02, 2010 1:05 PM
> > To: m...
> > Subject: [msp430] Buffer Problem
> >
> > Background:
> > - using MSP430F122
> > - using IAR kickstart
> >
> > I'm trying to implement a circular buffer somewhat similar to IAR appnote 430-03. However my buffer needs to be substantially larger. Even though I have plenty of space (program is about 3.5K), the IAR compiler balks with message:
> > ----------------
> > Error[e16]: Segment CSTACK (size: 0x50 align: 0x1) is too long for segment definition. At least 0x13 more bytes needed. The problem occurred while processing the segment placement command
> > "-Z(DATA)CSTACK+_STACK_SIZE#", where at the moment of placement the available memory ranges were "CODE:2C3-300"
> > Reserved ranges relevant to this placement:
> > CODE:200-203 DATA16_I
> > CODE:204-2C2 DATA16_Z
> > -------------
> >
> > My buffers are declared at top of file:
> >
> > unsigned char queueType[64];
> > unsigned char queueData[64];
> >
> > Anyone know how I can make these buffers larger?
> >
> > TIA.

Start a New Thread

you are using a part with very limited ram, you need to move as many constants
as possible to flash and you need to be careful of the depth of your calls and
how many paramaters get pushed on the stack... whenever possible try not and
pass data directly rather pass an address to the data buffer, you can quickly
eat up your stack/memory space when passing parameters..

if you need more ram go to a newer part or the 1611 which is in the same family
but with significantly more ram...

________________________________
From: baxtercodeworks
To: m...
Sent: Thu, December 2, 2010 1:05:18 PM
Subject: [msp430] Buffer Problem

 
Background:
- using MSP430F122
- using IAR kickstart

I'm trying to implement a circular buffer somewhat similar to IAR appnote
430-03. However my buffer needs to be substantially larger. Even though I have
plenty of space (program is about 3.5K), the IAR compiler balks with message:
----------------
Error[e16]: Segment CSTACK (size: 0x50 align: 0x1) is too long for segment
definition. At least 0x13 more bytes needed. The problem occurred while
processing the segment placement command

"-Z(DATA)CSTACK+_STACK_SIZE#", where at the moment of placement the available
memory ranges were "CODE:2C3-300"
Reserved ranges relevant to this placement:
CODE:200-203 DATA16_I
CODE:204-2C2 DATA16_Z
-------------

My buffers are declared at top of file:

unsigned char queueType[64];
unsigned char queueData[64];

Anyone know how I can make these buffers larger?

TIA.



Start a New Thread

On 2010-12-02 22:34, baxtercodeworks wrote:
> Pursuant to other research, I'm looking at lnk430F122.xcl and I find
> that -D_HEAP_SIZEP. I'm not doing any mallocs, can I grab some of the
> heap for my buffers? If so, do I just set -D_HEAP_SIZE smaller, or do I
> need to do more?

Hi!

If you're not using the heap, it will not be included in your application.

However, the stack will always be included, so you could try to reduce
it. However, it you reduce it too much and your application use more
stack that it is assigned, if will fail in non-obvious ways.

One way to figure out exactly how much RAM your application is using is
to "fake" the RAM size by modifying a custom linker command file. That
way you could look at the linker map file to see exactly what is placed
in RAM.

Good luck with your hunt!

-- Anders Lindgren, IAR Systems
--
Disclaimer: Opinions expressed in this posting are strictly my own and
not necessarily those of my employer.

Start a New Thread

1. by "custom linker command file", I assume you're talking about overriding the XCL file name.

2. In thrashing around a bit with malloc, I found that I was using the CLIB and malloc was not available. Any downsides of moving to the DLIB?

3. Looking at moving a command table to Flash, I find that (at runtime) the table has a very different memory address from the buffer(s) and they won't conflict. In playing around with various sizes, etc, it almost looks like the buffer size is limited or affected by the segment size (128 bytes)- not sure what is going on there.

4. Wasn't generating a map file, will do that and see if that helps any.
--- In m..., Anders Lindgren wrote:
>
> On 2010-12-02 22:34, baxtercodeworks wrote:
> > Pursuant to other research, I'm looking at lnk430F122.xcl and I find
> > that -D_HEAP_SIZEP. I'm not doing any mallocs, can I grab some of the
> > heap for my buffers? If so, do I just set -D_HEAP_SIZE smaller, or do I
> > need to do more?
>
> Hi!
>
> If you're not using the heap, it will not be included in your application.
>
> However, the stack will always be included, so you could try to reduce
> it. However, it you reduce it too much and your application use more
> stack that it is assigned, if will fail in non-obvious ways.
>
> One way to figure out exactly how much RAM your application is using is
> to "fake" the RAM size by modifying a custom linker command file. That
> way you could look at the linker map file to see exactly what is placed
> in RAM.
>
> Good luck with your hunt!
>
> -- Anders Lindgren, IAR Systems
> --
> Disclaimer: Opinions expressed in this posting are strictly my own and
> not necessarily those of my employer.
>

Start a New Thread

Hi!

On 2010-12-03 21:26, baxtercodeworks wrote:
> 1. by "custom linker command file", I assume you're talking about
> overriding the XCL file name.

Yes.
> 2. In thrashing around a bit with malloc, I found that I was using the
> CLIB and malloc was not available. Any downsides of moving to the DLIB?

CLib do have an implementation of malloc. However, I would recommend
using DLib as it provides lots more features and complies to the
standards. (The CLib library is basically only provided for backward
compatibility.)

DLib contains much, much more functions as it includes the full C99
runtime library. However, when using features provided by both
libraries, DLib should be as small, or smaller, than CLib even though it
might wary from function to function.

The CLib and DLib library is based on the same code, when it comes to
the low-level routines like the startup code and math routines that
corresponds to operators like +, -, *, /. However, the things that
differ are routines written in C.

An advantage of DLib is that only one hardware breakpoint is needed for
all kind of communication between the library and the debugger. CLib
requires one for "putchar", one for "exit" etc.

Finally, if your application overrides low-level CLib routines for
output (__putchar) or a custom printf-variant, they would have to be
reimplemented in terms of DLib primitives (__write etc.)
> 3. Looking at moving a command table to Flash, I find that (at runtime)
> the table has a very different memory address from the buffer(s) and
> they won't conflict. In playing around with various sizes, etc, it
> almost looks like the buffer size is limited or affected by the segment
> size (128 bytes)- not sure what is going on there.

If you place them in normal "const" memory, they should end up in
DATA16_C. This memory is not affected by segmentation.

On the other hand, if you explicitly place it in "INFOA", it has a
limited size, which is clearly seen in the linker command file.

Even though both of them are placed in flash, the idea is that read-only
data should be placed in normal "const" memory (i.e. DATA16_C), whereas
things that could be modified by reprogramming the flash should be
stored in info-memory.
> 4. Wasn't generating a map file, will do that and see if that helps any.

Please do, it's a great source of information on how the final
application is constructed. It can, for example, be used to find parts
that could be trimmed away.

-- Anders Lindgren, IAR Systems
--
Disclaimer: Opinions expressed in this posting are strictly my own and
not necessarily those of my employer.

Start a New Thread

Simon-said-he's smart- but he's a moron :

* Tip: Get you head out of your backside and put your 'story' writing
skills into writing a fiction novel!

* You obviously can't supply any real technical substance > on here!

Really, OK - I warned not to test me - OK, next step (this your OWN doing
Paul Curtis, I gave you a too many chances)

Hi Leon (Heller),

Have you ever wondered what Paul Curtis thought of your contract work ?

At this stage - I'll send it directly to you in near future.

When you see the context, it's up to you what you decide to do.

I'm trying to be gentle, but Paul isn't particularly nice about you.. To say
the least.

(Please note Leon that I NEVER - EVER asked anything about all the poison he
spits at you.

Unlike Simon said below (aka Paul), I send warm Emails and try - as best as
I can - to "drop a line" here & there on occasion.

Ok, now you - Simon-said :

I had a quick glance, and found a *massive* amount of "seemingly" dumb
questions by our Sharp & fast

resident expert : Simon-baxter !!!!... (forwarded at the end)

Stay tuned - this is rich guys - you're gonna love it.

Interestingly, same said Simon (pun intended) "BLOATS his Inbox" on MSP430
Yahoo group (I'll leave it there for now)

... and you guessed it.. They're all CATEGORICAL "dumb" questions ? no
siree... they're wittingly, cunningly and without mercy,

designed to "slander" . "legally". you guessed it again.. IAR !!!!!!!!!!

Come on Paul,

Give it a rest - for Christ's sake.

For the record, I'm also fwding this (back) to the MSP430 and SAM9 group.

Paul, keep escalating, and my next step is start sending *all* your poison
to dozens and dozens of parties involved.

I don't know about others, but I'm sick of all the deceipt (which again, for
the record, I never solicited, au contraire)

You've woven for yourself for years now.

I've trusted you for 8 years, and now you have betrayed my trust for the
LAST time.

I WARNED you several times PRIVATELY to back off.. But nooooooo

The almighty Paul Curtis is NEVER, NEVER wrong .. Now is he ????

I wonder how many members on all these groups (not to mention RAL clients)
are SICK to DEATH of being treated like shit

as a customer.

To quote the Bible (seems applicable with all this 6666 talk :-)

"Show me a Liar and I'll show you a thief".

Oh, Simon by the way, talking about fiction, did you actually know that Mark
Twain's name was actually Samuel Clements (or some such)

and that he was one of the closest friends of Nikolai Tesla...

_____

From: m... [mailto:m...] On Behalf Of
baxtercodeworks
Sent: Friday, 3 December 2010 7:30 AM
To: m...
Subject: [msp430] Re: Buffer Problem

I've got a similar program that runs on the MSP430F1121a - which has only
128 bytes ram, and it can handle a slightly larger buffer. I've tried
eliminating variables (consts, statics, locals, etc.) sometimes gaining a
little, but mostly without gaining anything.

I do have a command table that is currently const, that could possibly go
into Flash memory, but I'm unsure how to do that given that I'm already
putting some data there using '__root const ... '.

--- In m... , "Hayashi,
Steve" wrote:
>
> Looking at your data types and looking at the specs for the F122, I don't
think you can make the buffer much larger than you have it. The processor
only has 256 bytes of RAM and those two buffers occupy half of it.
>
> In short, you've run out of RAM. A google search on DATA16_Z shows quite a
number of people having similar problems as you.
>
> -Steve
>
> -----Original Message-----
> From: m...
[mailto:m... ] On Behalf
Of baxtercodeworks
> Sent: Thursday, December 02, 2010 1:05 PM
> To: m...
> Subject: [msp430] Buffer Problem
>
> Background:
> - using MSP430F122
> - using IAR kickstart
>
> I'm trying to implement a circular buffer somewhat similar to IAR appnote
430-03. However my buffer needs to be substantially larger. Even though I
have plenty of space (program is about 3.5K), the IAR compiler balks with
message:
> ----------------
> Error[e16]: Segment CSTACK (size: 0x50 align: 0x1) is too long for segment
definition. At least 0x13 more bytes needed. The problem occurred while
processing the segment placement command
> "-Z(DATA)CSTACK+_STACK_SIZE#", where at the moment of placement the
available memory ranges were "CODE:2C3-300"
> Reserved ranges relevant to this placement:
> CODE:200-203 DATA16_I
> CODE:204-2C2 DATA16_Z
> -------------
>
> My buffers are declared at top of file:
>
> unsigned char queueType[64];
> unsigned char queueData[64];
>
> Anyone know how I can make these buffers larger?
>
> TIA.
>
>
>
> Start a New Thread

Kris,

> Simon-said-he's smart- but he's a moron :
> Unlike Simon said below (aka Paul), I send warm Emails and try - as
> best as I can - to "drop a line" here & there on occasion.

I do not happen to be Simon Baxter and I have nothing in common with
baxtercodeworks.com.

> Stay tuned - this is rich guys - you're gonna love it.

This is pure tragedy.

> Interestingly, same said Simon (pun intended) "BLOATS his Inbox" on
> MSP430 Yahoo group (I'll leave it there for now)
> ... and you guessed it.. They're all CATEGORICAL "dumb" questions ? no
> siree... they're wittingly, cunningly and without mercy,
> designed to "slander" . "legally". you guessed it again.. IAR
> !!!!!!!!!!

You're accusing me of using a pseudonym designed to slander IAR?

That's one hell of an accusation.

I hope you can back that up with proof. Where is it?

> I've trusted you for 8 years, and now you have betrayed my trust for
> the LAST time. I WARNED you several times PRIVATELY to back off.. But
nooooooo

Unfortunately, you seemed to think I have hidden behind a pseudonym to
support myself. No, I can categorically state I have not.
> The almighty Paul Curtis is NEVER, NEVER wrong .. Now is he ????
> I wonder how many members on all these groups (not to mention RAL
> clients) are SICK to DEATH of being treated like shit
> as a customer.

Tim and Simon can speak for themselves; I do not speak for them, or request
they speak on my behalf.

> To quote the Bible (seems applicable with all this 6666 talk :-)
> "Show me a Liar and I'll show you a thief".
> Oh, Simon by the way, talking about fiction, did you actually know that
> Mark Twain's name was actually Samuel Clements (or some such)

If you are alluding to the fact that I have a pseudonym as Simon Baxter and
something to do with baxtercodeworks, you're tragically mistaken.

--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
SolderCore arriving Winter 2010! http://www.soldercore.com

Start a New Thread