Problem with old code and newer compiler

[MarkW]

I developed a project back in 2009 using Swordfish. I do not know the version of the compiler but it was one that required the USB key. When I switched over to Windows 7 (from XP) SF would not work. I purchased an upgrade in Feb 2011. It is version 2205 ICC1.1.5.5.

The original project has come back up and the customer required a small change to the code. When I compile the old code with the newer compiler I get some strange results. A good deal of the code works OK but I copied one small example of a problem area here:

Code: Select all

Sub VerifyRamVar(ByRef pValue As Word)
    Dim tempx As Word
 
    //Check the 'temp' local variable             
    tempx = 43690
    //////tempx =     %1010101010101010
    Debug(DecToStr(tempx),CR,LF)     <<-- Prints out 14250
 
    If tempx <> 43690 Then
    //////If tempx <> %1010101010101010 Then
        Fault = 8
        Exit
    EndIf
    tempx = %0101010101010101
    If tempx <> %0101010101010101 Then
        Fault = 9
        Exit
    EndIf            

The intent was to check each variable with an alternating bit pattern (UL requirement in the project). The original code loaded the binary version. I tried using the decimal equivalent while testing. The debug statement show tempx = 14250 (decimal) . In other words - loading a 16 bit number into a word and reading the word back doesn't return the same number.

Do I need to upgrade the compiler again? Or am I doing something wrong?

Any help would be welcome.

Mark

[David Barker]

Program works correctly

Code: Select all

' version 2.2.1.8
' ICC 1.1.6.1
Include "usart.bas"
Include "convert.bas"

Sub VerifyRamVar(ByRef pValue As Word)
    Dim tempx As Word
 
    //Check the 'temp' local variable             
    tempx = 43690
    //////tempx =     %1010101010101010
    usart.write(DecToStr(tempx),13,10)   
 
    If tempx <> 43690 Then
    //////If tempx <> %1010101010101010 Then
      '  Fault = 8
        Exit
    EndIf
    tempx = %0101010101010101
    If tempx <> %0101010101010101 Then
       ' Fault = 9
        Exit
    EndIf            
 End Sub
 
 Dim value As Word
 usart.setbaudrate(br19200)
 VerifyRamVar(value)

[MarkW]

Thank you for your reply David.

I'll look into this issue a bit more on Monday.

I did do a little detective work prior to seeing your reply. I had an older computer at home that still has XP Pro installed. I installed the old version of Swordfish (with USB key) onto that computer and tried compiling the same source file. When executed, it works as expected. I also noted that the hex file size is 58K on the old version and 63K on the new version. There is also about a 1K difference in the reported memory usage.

I'm not sure what this means in relation to my problem - just explaining what I'm seeing.

Old = XP Pro SF ver: 1.2.0.8 ICC 1.1.4.6
New = W7 32 Pro SF ver: 2.2.0.5 ICC 1.1.5.5

How can I go about updating my compiler? I'm willing to try that first.

Thank you,
Mark

[David Barker]

Update from HELP...ABOUT

[MarkW]

Clicking on View -> Online Updates does not seem to work. I get no messages of any kind and the version stays the same.

I have emailed Mecanique inquiring about buying an upgrade disk.

Here is the stripped down code:

Code: Select all

Device = 18F4520
Clock = 32
Dim i As Word

Config
    OSC = INTIo67,
    Debug = OFF,
    MCLRE = off,
    BOREN = SBORDIS,    
    BORV = 2,
    WDTPS = 64,
    WDT = ON,
    CP0 = ON,
    CP1 = ON,
    CPB = ON,
    WRTC = ON
    
#option WDT = false

Include "USART.bas"
Include "Convert.bas"

OSCCON = %01110000  '8 MHz internal osc
OSCTUNE = %01000000 'Turn PLL on (32 MHz clock)

// Set hardware UART baud rate 
USART.SetBaudrate(br19200)

DelayMS(100)

While true
     USART.Write(13,10,"Loop",13,10)
 
    i = 43690
    USART.Write(DecToStr(i),13,10)
    If i <> 43690 Then
        USART.Write("   No match",13,10)
    EndIf
    
      
    DelayMS(500)
Wend

i = 170 and "No Match" prints every time.
The same code runs without problems on the old compiler.

Odd thing is if I change the number up or down one digit it works as expected.
If I try %0101010101010101 (21845 base 10) I see the same problem.

Also, if I put another number into i, like 43691 after the comparison, i shows a value of 170 the first time through the loop but shows the correct value each time thereafter.

I downloaded the SE version and it does the same thing. So maybe a newer compiler isn't the answer.
I am going to try this little program at home tonight and see what happens. Maybe I have some odd computer issue here at the office.
I've even tried two different programmers with no luck.

I'm totally perplexed.

Thank you,
Mark

[Jerry Messina]

Here's a hint as to what's going on

43690 = $AAAA
170 = $00AA

When I compiled your example with either 2.2.0.5 or SE 2.2.1.6 (both ICC1155), I got the following for the assignment

Code: Select all

?I000044_F000_000035_M000000 ; L#MK I = 43690
        MOVLW 170
        MOVWF M1_U16,0
        MOVWF M1_U16,0    <<< ONE OF THESE SHOULD BE 'M1_U16H'

It's only setting the low byte of 'I', so the high byte remains uninitialized. It seems to do this with any value where highbyte=lowbyte, so $5555, $C3C3, etc also fail.

When I used the latest version 2.2.1.8 (ICC1163), I get

Code: Select all

?I000050_F000_000035_M000000 ; L#MK I = 43690
    MOVLW 170
    MOVWF M1_U16H,0
    MOVWF M1_U16,0

Which is loading 'AA' into both high and low bytes.

I'm not sure which version fixed this.

[MarkW]

I just found the same thing!
I haven't touched assembly stuff for years and wasn't sure if that might be the problem. But it looks suspicious!

The my newer compiler has the error (at least I'm assuming its an error). The old version does not.

If I change the value to 43691 (0xAAAB) I see that the new compiler splits that into two lines:

?I000044_F000_000035_M000000 ; L#MK I = 43691
MOVLW 171
MOVWF M1_U16,0
MOVLW 170
MOVWF M1_U16H,0

Thanks for verifying the issue!

I tried using the SE version and it has the same problem.

Looks like I need to plead for a way to get 2.2.1.8 as the online update does not do anything.

Mark

[David Barker]

As shown in my previous post, the code works correctly with the latest compiler. I would prefer to keep error reporting to the current version of the compiler. I'm not sure if I see the merits of discussing code generated by an older version of the compiler.

The issue here is that you are unable to access the latest updates, as you are using a very old version of the compiler. I have emailed you directly the instructions you need for you to update the compiler. If the problem persists after using the latest compiler version, please do let me know. I will also upload a new SE version as soon as I get time...

[MarkW]

Thank you David. I would have surely tried 2.2.1.8 had I been able to obtain it. The link you provided allowed me to change to the new compiler and it solved the problem. I very much appreciate your help in getting me back on track.

[David Barker]

That's great news, thanks for letting me know...