> Hi Al, you got it. I was testing using a program I
made and it was
>starting at 0x9000, that resulted in the Error 446. Moving the start
>to 0x1100 did solve it.
> Then I also did a try with:
> add.w #2-$,r15
> add.w#(2-$),r15
> In both cases the assembler did calculate correctly.
> As you pointed out device type seems to be the issue since Jons
>experiments where also in lower memory.
> My target device is '149.
I get fully understandable results when I apply an ORG statement. But
this tells the assembler, prior to the link process, where things are
located. I'm exploring the link process with relocatable segments and
without specifying an ORG.
For example, asm81.s43 (complete source, below) produces results I
completely embrace and understand. However, with a very slight
modification to it, merely changing the ASEG to an RSEG, it produces
entirely different code for some of the instructions. And if you
comment out the ORG after that, again different but still not what I'd
expect.
I am struggling with this, a bit. I imagine there is a linker file --
it's called lnk430f149.xcl -- and the memory areas it sets up are:
P.S. I stuffed the start vector segment at the bottom and used ENDMOD
to isolate the two modules from each other, despite being in the same
source file. Just to keep that ORG down below, in the source, rather
than up above where some (me, too) may be confused by its presence.
......asm81.s43.....
#include "msp430x14x.h"
NAME main
PUBLIC init
RSEG CSTACK
ASEG CODE ; <--- note ASEG, not RSEG
ORG 1100H ; <--- note ORG used
init: mov #SFE(CSTACK), SP ; set up stack
mov.w #WDTPW+WDTHOLD,&WDTCTL ; stop watchdog
main:
add #$, r15
add #-$, r15
add #(0-$), r15
add #(2-$), r15
add #($-0), r15
add #($-2), r15
add #-($-2), r15
me EQU $
add #(0x0002-me), r15
jmp $
ENDMOD
>Hi Jon,
> This is what I do when I start a new project.
Gotcha, Al. One issue I want to clarify, before saying more. I note
that you use ORG 1000H. I'm intentionally attempting to do this with
relocatable segment code. It's important that the actual location be
deferred until link time. If you could, would you consider using
whatever methods you use for relocatable segments on this? Or do you
use them, at all?
(This all relates to some experiments with the c compiler.)
Jon
Reply by OneStone●September 20, 20092009-09-20
Hi Jon,
This is what I do when I start a new project.
Open the workspace.
Create a new project
make it asm only
Go back into the workspace and delete the IAR provided asm shell file
then roll in my own simple shell file which basically looks like thast
below. This may seem pedantic, but i got into the habit years ago when I
found that such simple things saved me from getting files all crossed up
whenever I tried to upgrade IAR. It works, it's a minor inconvenience. i
don't tend to use SEGMENT assignments, i don't need to, or want to, I
prefer to manage all of that myself, I don't need, nor ever expect to
need to write relocatable code, or anything else which might require me
to trust a program to manage any of my memory for me, therefore I see no
need to mess with that. #include and the occasional ORG or EVEN is all
I need to manage memory allocation and keep things straight.
i wouldn't make any assumptions about what #include "msp430.h" does. I
would rather be specific. Also I tend to modify the header files to
include other information I find valuable, and to drop all the stuff I
find superfluous. i aslo make my own comments, which i find more
meaningful,bELOW THIS IS THE LISTING FROM MY OWN ATTEMPT AT A RAW SIMPLE
ASM FILE USING MSP430.H
#include "MSP430F2131.H" ;Hardware Register definitions
#include "ULOG_HDR.S43" ;Constants, variables and flags
#include "ULOG_MAIN.S43" ;Constants, variables and flags
#include "ULOG_INIT.S43"
#include "ULOG_ICC.S43"
#include "ULOG_UART.S43"
#include "FLASH.S43"
BELOW here I took the IAR default asm file then scrubbed the segment
stuff, because it appears to be setting the PC to FFFe with the ORG
statement. I then tried to compile and the MOV #SFE(CSTACK) ,SP was
giving an error, so I just replaced it, as it's really irrelevant to the
aim, anyway clean up the asm shell and it compiles as expected.
program
18 00E006 B240805A2001 MOV.W #WDTPW+WDTHOLD,&WDTCTL
; Stop
watchdo
g
timer
19 00E00C FF3F JMP $
; jump
to current location
'$'
20 00E00E END
Cheers
AL
Jon Kirwan wrote: > On Mon, 21 Sep 2009 07:27:40 +0930, you wrote:
>
>> Hi Jon, sorry if I'm responsible for returning your sanity, I personally
>> feel much better off without mine! I'd lay odds it's a compiler
issue,
>> but you're certainly more than welcome to the mild assist.
>
> Well... I'm still having problems. Set up a workspace, select the
> MSP430F149 as the target. Mark the project as "assembler only," of
> course. I'm not linking any library, either. Select the simulator
> instead of a FET Tool (just in case.)
>
> (I used the generic #include in the code below. I believe it selects
> the appropriate include file for the specific processor.)
>
> #include "msp430.h"
>
> NAME main
> PUBLIC main
> ORG 0FFFEh
> DC16 init
> RSEG CSTACK
> RSEG CODE
> init: MOV #SFE(CSTACK), SP ; set up stack
> MOV.W #WDTPW+WDTHOLD,&WDTCTL ; stop watchdog
> main:
> add #$, r15
> add #-$, r15
> add #(0-$), r15
> add #(2-$), r15
> add #($-0), r15
> add #($-2), r15
> add #-($-2), r15
> me EQU $
> add #(0x0002-me), r15
> JMP $
>
> END
>
> Then move into the simulator and open up a disassembly window and look
> at the binary word values loaded there. Compare.
>
> I'm still getting the same issue with 4.20.1 (4.20.1.50017).
>
> Thanks in advance,
> Jon
>
Reply by Jon Kirwan●September 20, 20092009-09-20
On Mon, 21 Sep 2009 07:27:40 +0930, you wrote:
>Hi Jon, sorry if I'm responsible for returning
your sanity, I personally
>feel much better off without mine! I'd lay odds it's a compiler
issue,
>but you're certainly more than welcome to the mild assist.
Well... I'm still having problems. Set up a workspace, select the
MSP430F149 as the target. Mark the project as "assembler only," of
course. I'm not linking any library, either. Select the simulator
instead of a FET Tool (just in case.)
(I used the generic #include in the code below. I believe it selects
the appropriate include file for the specific processor.)
#include "msp430.h"
NAME main
PUBLIC main
ORG 0FFFEh
DC16 init
RSEG CSTACK
RSEG CODE
init: MOV #SFE(CSTACK), SP ; set up stack
MOV.W #WDTPW+WDTHOLD,&WDTCTL ; stop watchdog
main:
add #$, r15
add #-$, r15
add #(0-$), r15
add #(2-$), r15
add #($-0), r15
add #($-2), r15
add #-($-2), r15
me EQU $
add #(0x0002-me), r15
JMP $
END
Then move into the simulator and open up a disassembly window and look
at the binary word values loaded there. Compare.
I'm still getting the same issue with 4.20.1 (4.20.1.50017).
Thanks in advance,
Jon
Reply by OneStone●September 20, 20092009-09-20
Hi Jon, sorry if I'm responsible for returning your sanity, I personally
feel much better off without mine! I'd lay odds it's a compiler issue,
but you're certainly more than welcome to the mild assist.
Al
Jon Kirwan wrote: > On Mon, 21 Sep 2009 07:04:46 +0930, you wrote:
>
>> IAR Assembler V4.20.1.50017/W32
>
> Your output is different from mine, obviously. I'm thinking now that
> this was an issue with:
> V4.11B/W32 (4.11.2.9)
>
> I'll update to a newer version and re-check.
>
> If this is a problem with 4.11 and not with 4.20, I guess it surprises
> me to find that a version 4 assembler would have such problems. But
> it remains for me to update first and verify. I have some other work
> going on with the computer, right now, plus some visitors, so it will
> be an hour or so more before I can check this.
>
> Thanks very, very much, though. This helps bring my sanity back, I
> think. (I'm just hoping I don't have to be shocked with IAR and it
is
> still something else.)
>
> Jon
>
Reply by Jon Kirwan●September 20, 20092009-09-20
On Mon, 21 Sep 2009 07:04:46 +0930, you wrote:
>IAR Assembler V4.20.1.50017/W32
Your output is different from mine, obviously. I'm thinking now that
this was an issue with:
V4.11B/W32 (4.11.2.9)
I'll update to a newer version and re-check.
If this is a problem with 4.11 and not with 4.20, I guess it surprises
me to find that a version 4 assembler would have such problems. But
it remains for me to update first and verify. I have some other work
going on with the computer, right now, plus some visitors, so it will
be an hour or so more before I can check this.
Thanks very, very much, though. This helps bring my sanity back, I
think. (I'm just hoping I don't have to be shocked with IAR and it
is
still something else.)
Jon
Reply by Augusto Einsfeldt●September 20, 20092009-09-20
Hi Al, you got it. I was testing using a program I made and it was
starting at 0x9000, that resulted in the Error 446. Moving the start
to 0x1100 did solve it.
Then I also did a try with:
add.w #2-$,r15
add.w#(2-$),r15
In both cases the assembler did calculate correctly.
As you pointed out device type seems to be the issue since Jon´s
experiments where also in lower memory.
My target device is '149.
-Augusto
On Dom 20/09/09 18:23 , OneStone o...@bigpond.net.au sent:
Hi JOn, when I quickly loaded up an existing program and just pasted
that into the front of my code this is what happened:_
00E126 503F E126 add.w #$, r15 ; 1. expected
Error[446]: Number out of range. Valid range is -32768 (-0x8000) to
65535 (0xFFFF).
So I looked a little longer and then shifted the test code down to
info
memory at 1080 and here's the result:_
83 001080 3F508010 add.w #$, r15 ; 1. expected
84 001084 3F507CEF add.w #-$, r15 ; 2.
expected
85 001088 3F5078EF add.w #(0-$), r15 ; 3.
expected
86 00108C 3F5076EF add.w #(2-$), r15 ; 4.
expected
87 001090 3F509010 add.w #($-0), r15 ; 5.
expected
It seems that the result is being affected by the position in
memory, OR
the size of memory/chip type, almost as if it wasn't treating $ as a
literal value but trying to rationalise it as an address
Al
Jon Kirwan wrote:
> On Sun, 20 Sep 2009 20:33:28 +0000, Augusto wrote:
>
>> Hello Jon,
>> What do you see and what did you expect?
>> The erroneous result would be incremented by 2 or subtracted by 2
in
>> case you do 4-$?
>> 2-$ would (almost) allways result in a negative number. Maybe
>> inspecting the value you got would give a hint. I assume you
already
>> did that but without the values this audience can do very little.
>> -Augusto
>
> Sorry, Augusto. I should have said what I observed.
>
> I'll provide the program counter:
>
> 001126 503F 1126 add.w #$, r15 ; 1. expected
> 00112A 503F EED6 add.w #-$, r15 ; 2. expected
> 00112E 503F 10EA add.w #(0-$), r15 ; 3. not expected
> 001132 503F 10E8 add.w #(2-$), r15 ; 4. not expected
> 001136 503F 1136 add.w #($-0), r15 ; 5. expected
> 00113A 503F 1138 add.w #($-2), r15 ; 6. expected
> 00113E 503F EEC4 add.w #-($-2), r15 ; 7. expected
> h equ $
> 001142 503F EECO add.w #(2-h), r15 ; 8. expected
>
> Hope that helps. Note and compare (4) and (7), too.
>
> Thanks in advance for your thoughts.
>
> Jon
>
>
>
>
>
>
>
Reply by OneStone●September 20, 20092009-09-20
Sorry, to clarify this. The micro my code was written for is the
MSP430F2131, but my code starts at F800, so I plonked your test code at
E126. The firsy 6K or so of flash memory is reserved for data logging so
was clean. The error seemed strange so, i decided to move it downwards.
Since i don't have any flash at 1100H I went as close as possible, into
the first naked info memory segment, which was 1080, and lo and behold,
she compiles. sO i THEN WENT BACK AND DECIDED TO COMPILE THE CODE AT
IMAGINARY MEMORY ADDRESS 1126h, WHICH DOESN'T ACTUALLY EXIST ON THE
2131. THE RESULTS OF THIS ARE BELOW AS YOU CAN SEE, ALONG WITH THE
COMPILER VERSION i'M USING.:-
Al
OneStone wrote: > Hi JOn, when I quickly loaded up an existing program
and just pasted
> that into the front of my code this is what happened:_
>
> 00E126 503F E126 add.w #$, r15 ; 1. expected
> Error[446]: Number out of range. Valid range is -32768 (-0x8000) to
> 65535 (0xFFFF).
>
> So I looked a little longer and then shifted the test code down to info
> memory at 1080 and here's the result:_
>
> 83 001080 3F508010 add.w #$, r15 ; 1. expected
> 84 001084 3F507CEF add.w #-$, r15 ; 2. expected
> 85 001088 3F5078EF add.w #(0-$), r15 ; 3. expected
> 86 00108C 3F5076EF add.w #(2-$), r15 ; 4. expected
> 87 001090 3F509010 add.w #($-0), r15 ; 5. expected
>
> It seems that the result is being affected by the position in memory, OR
> the size of memory/chip type, almost as if it wasn't treating $ as a
> literal value but trying to rationalise it as an address
>
> Al
>
> Jon Kirwan wrote:
>> On Sun, 20 Sep 2009 20:33:28 +0000, Augusto wrote:
>>
>>> Hello Jon,
>>> What do you see and what did you expect?
>>> The erroneous result would be incremented by 2 or subtracted by 2 in
>>> case you do 4-$?
>>> 2-$ would (almost) allways result in a negative number. Maybe
>>> inspecting the value you got would give a hint. I assume you already
>>> did that but without the values this audience can do very little.
>>> -Augusto
>> Sorry, Augusto. I should have said what I observed.
>>
>> I'll provide the program counter:
>>
>> 001126 503F 1126 add.w #$, r15 ; 1. expected
>> 00112A 503F EED6 add.w #-$, r15 ; 2. expected
>> 00112E 503F 10EA add.w #(0-$), r15 ; 3. not expected
>> 001132 503F 10E8 add.w #(2-$), r15 ; 4. not expected
>> 001136 503F 1136 add.w #($-0), r15 ; 5. expected
>> 00113A 503F 1138 add.w #($-2), r15 ; 6. expected
>> 00113E 503F EEC4 add.w #-($-2), r15 ; 7. expected
>> h equ $
>> 001142 503F EECO add.w #(2-h), r15 ; 8. expected
>>
>> Hope that helps. Note and compare (4) and (7), too.
>>
>> Thanks in advance for your thoughts.
>>
>> Jon
>>
Reply by Augusto Einsfeldt●September 20, 20092009-09-20
Hi Jon,
It is at least an interesting topic to try an explanation.
The incorrect values are calculated accordingly, so the constants 0
and 2 are evaluated. As proven in the line 2 the calculation for -$
is also correctly evaluated.
Lines 5 to 8 proves the equation format is not the sole responsible.
So, in my humble opinion it is a very specific compiler flaw where it
gets a wrong value for $ only when it is the subtrahend inside
parenthesis.
I wonder if the statement add.w #2-$,r15 would work whitout the
parenthesis.
I did try to test it here in my IAR (IAR Assembler for MSP430
V4.10E/W32 (4.10.5.9)) but it is giving an error:
Error[446]: Number out of range. Valid range is -32768 (-0x8000) to
65535 (0xFFFF). test.asm 50
It seems that I have to get a newer version for IAR...
Best regards,
Augusto
On Dom 20/09/09 17:48 , Jon Kirwan j...@infinitefactors.org sent:
On Sun, 20 Sep 2009 20:33:28 +0000, Augusto wrote:
> Hello Jon,
> What do you see and what did you expect?
> The erroneous result would be incremented by 2 or subtracted by 2
in
>case you do 4-$?
> 2-$ would (almost) allways result in a negative number. Maybe
>inspecting the value you got would give a hint. I assume you
already
>did that but without the values this audience can do very little.
> -Augusto
Sorry, Augusto. I should have said what I observed.
I'll provide the program counter:
001126 503F 1126 add.w #$, r15 ; 1. expected
00112A 503F EED6 add.w #-$, r15 ; 2. expected
00112E 503F 10EA add.w #(0-$), r15 ; 3. not expected
001132 503F 10E8 add.w #(2-$), r15 ; 4. not expected
001136 503F 1136 add.w #($-0), r15 ; 5. expected
00113A 503F 1138 add.w #($-2), r15 ; 6. expected
00113E 503F EEC4 add.w #-($-2), r15 ; 7. expected
h equ $
001142 503F EECO add.w #(2-h), r15 ; 8. expected
Hope that helps. Note and compare (4) and (7), too.
Thanks in advance for your thoughts.
Jon
Reply by OneStone●September 20, 20092009-09-20
Hi JOn, when I quickly loaded up an existing program and just pasted
that into the front of my code this is what happened:_
00E126 503F E126 add.w #$, r15 ; 1. expected
Error[446]: Number out of range. Valid range is -32768 (-0x8000) to
65535 (0xFFFF).
So I looked a little longer and then shifted the test code down to info
memory at 1080 and here's the result:_
It seems that the result is being affected by the position in memory, OR
the size of memory/chip type, almost as if it wasn't treating $ as a
literal value but trying to rationalise it as an address
Al
Jon Kirwan wrote: > On Sun, 20 Sep 2009 20:33:28 +0000, Augusto wrote:
>
>> Hello Jon,
>> What do you see and what did you expect?
>> The erroneous result would be incremented by 2 or subtracted by 2 in
>> case you do 4-$?
>> 2-$ would (almost) allways result in a negative number. Maybe
>> inspecting the value you got would give a hint. I assume you already
>> did that but without the values this audience can do very little.
>> -Augusto
>
> Sorry, Augusto. I should have said what I observed.
>
> I'll provide the program counter:
>
> 001126 503F 1126 add.w #$, r15 ; 1. expected
> 00112A 503F EED6 add.w #-$, r15 ; 2. expected
> 00112E 503F 10EA add.w #(0-$), r15 ; 3. not expected
> 001132 503F 10E8 add.w #(2-$), r15 ; 4. not expected
> 001136 503F 1136 add.w #($-0), r15 ; 5. expected
> 00113A 503F 1138 add.w #($-2), r15 ; 6. expected
> 00113E 503F EEC4 add.w #-($-2), r15 ; 7. expected
> h equ $
> 001142 503F EECO add.w #(2-h), r15 ; 8. expected
>
> Hope that helps. Note and compare (4) and (7), too.
>
> Thanks in advance for your thoughts.
>
> Jon
>
