Pumpkin, Inc.

Pumpkin User Forums

Ram assignment - confirmation

For issues specific to TI's MSP430 line of ultra-low-power microcontrollers, including compilers (e.g. Quadravox AQ430), IDEs (e.g. IAR Embedded Workbench) and development tools (e.g. TI MSP-FET430 Flash Emulation Tool).

Ram assignment - confirmation

Postby Phil W » Mon Apr 21, 2003 10:25 am

Hi again,

Using the IAR compiler.

Can you verify for me that no-matter what combination of number of bytes used in counting, timing, etc that the MSP430 byte/word, odd/even address separation is maintained in mem.c

I'm having a strange problem that a semaphore seems to be signalled when in fact it has not been. Seems to happen after timer service routine is executed.

Just want verification from your end so that I can discount salvo.

regards
Phil

Phil W
 
Posts: 36
Joined: Tue Jan 14, 2003 12:00 am
Location: penrith nsw australia

Re: Ram assignment - confirmation

Postby aek » Tue Apr 22, 2003 6:31 am

Hi Phil.

I am not aware of any users who have been affected by this condition. There is nothing unique about Salvo's global objects vs. any that a user might create, odd- (char) or even (int)-sized.

The one place where Salvo access variables "unbeknownst to the compiler" is in portiar430.s43. Hoever, since that's pure assembly, and all accesses are word accesses, I don't think that this is the source of the problem.

In summary, I don't have any evidence that Salvo is affected by this bug. If you can provide me with the definitive problem description on this issue with the IAR compiler, I'd be happy to do a code review on it.

Have they fixed this in the v2.10A release?

------------------

-------
aek
aek
 
Posts: 1888
Joined: Sat Aug 26, 2000 11:00 pm

Re: Ram assignment - confirmation

Postby aek » Tue Apr 22, 2003 8:13 am

Hi Phil.

If this

quote:
(Matthew Bivans): I've run across a bug in the latest (1.26a) rev. of the IAR compiler for the MSP430. The compiler doesn't generate correct word addresses for auto variables located on the stack when the variable is declared in a sub-scope after code in a function. It's not an easy set of circumstances to explain, but if you compile the follow code in ew1.26a you'll see nVal end up at offset 13 from the SP!. The resulting assembly output is located below for both 1.24 and 1.26. If you run it in C-SPY you can see the misalignment clearly. It appears to be okay in ew1.24a.
reflects the issue that you're talking about, I cannot see how it would be affected by Salvo.

That's because the only stack-related issues are implemented in assembly, and they are all word-sized operations. So from reading the above, any alignment errors would be due to the compilers error(s) in accessing local (on-stack) variables, which has nothing to do with Salvo per se.

The current release was generated and tested with IAR MSP430 v1.26B.

Be sure that mem.c is a node in your project, and you should also check return codes from Salvo services.

------------------

-------
aek
aek
 
Posts: 1888
Joined: Sat Aug 26, 2000 11:00 pm

Re: Ram assignment - confirmation

Postby aek » Tue Apr 22, 2003 9:53 am

One more thing:
quote:
... auto variables located on the stack when the variable is declared in a sub-scope after code in a function.
AFAIK the Salvo source code does not contain any instances of this -- auto variables are always declared at the start of a function, before any code. And we don't use sub-scope (because not all compilers can handle it anyway ...).

------------------

-------
aek
aek
 
Posts: 1888
Joined: Sat Aug 26, 2000 11:00 pm

Re: Ram assignment - confirmation

Postby Phil W » Thu May 01, 2003 9:13 am

Hi aek,

I've given this possible even/odd address alignment problem some more thought.

I believe the problem will only arise if a variable's type is recast via pointer operations at run time. eg *(int *)&char

This operation leads to very efficent code generation but is very dangerous with cpu's, such as the msp430, that have address alignment restrictions.

To use this sort of coding in such circumstances, the programmer has to be aware of every starting address boundary for each global and static variable. He has to be sure, if he is casting a char to int or long etc, that he is refering to an even address.
Also this type of cast should never be applied to local variables (static may be ok provided an even number of bytes are declared) as you can never be sure of where they fall on the stack when created.

Actually, I believe that this type of casting is frowned on. If, for example, you pass this code through PC Lint, it will flag this cast as being dangerous.

So what does this mean to you and me?

Well, I use it.

In my side of the code I ensure I know where all my variables are and make sure when I use this casting, that I am operating on correct boundaries.

My unknown at the moment is salvo. If I can force salvo to be linked after all my code all should be ok.

But if you can enlighten me a little it may be helpful.

(1) Do you do any of this type of runtime casting?
(2) Do you declare any globals or statics in other files than mem.c?
(3) If you do, are they padded with a dummy char to give an even number of bytes for that file no matter what option is defined?

Thanks
Phil

Phil W
 
Posts: 36
Joined: Tue Jan 14, 2003 12:00 am
Location: penrith nsw australia

Re: Ram assignment - confirmation

Postby aek » Fri May 02, 2003 1:57 am

Hi Phil.
quote:
I believe the problem will only arise if a variable's type is recast via pointer operations at run time. eg *(int *)&char
That's interesting -- it suggests that the byte-alignment issue is potentially more widespread / more easily "triggered" than Matthew Bivans' suggestion.

BTW, we now have IAR MSP430C v2.10A in-house, and the next Salvo for MSP430 release will include source-code-level support for v2.10A. We are still evluating how we will do the switch from v1.26B- to v2.10A-compatible libraries, etc.

ALso, we will also be applying PC-Lint to the Salvo code in the near future (by end Q3 2003).

To your specific questions:

quote:
(1) Do you do any of this type of runtime casting?
No. The only run-time casts are (I believe) in delay2.c, initecb.c, inittcb.c and msgq3.c, and none follow the format you have identified. You're probably not using any of the corresponding API functions anyway ...
quote:
(2) Do you declare any globals or statics in other files than mem.c?
No -- all of Salvo's globals and statics are in mem.c.
quote:
(3) If you do, are they padded with a dummy char to give an even number of bytes for that file no matter what option is defined?
N/A becuase of (2) above.

So, my best guesses are:

1) You're using Salvo's messages or message queues, which require dereferencing, which in itself requires an explicit cast. This dereferencing is unavoidable since Salvo's message pointers are of type void *. My gut feeling is that this should not be an issue, since we have many Salvo+MSP430+IAR users, and this should have shown up by now ...

2) Perhaps there is an interaction with the Salvo MSP430 context-switcher and your tasks vis-a-vis byte boundaries. However, this seems unlikely, as the context switcher does only word-sized stack operations.

So the bottom line is that I really don't know what might be causing the problem. I would think that you can explicitly locate all of your ststics and globals in your own, named memory segment, though I haven't tried it ...

------------------

-------
aek
aek
 
Posts: 1888
Joined: Sat Aug 26, 2000 11:00 pm


Return to TI's MSP430

Who is online

Users browsing this forum: No registered users and 1 guest

cron