Serious ST7 Assembler BUG

[fggnrc]

Posted on June 19, 2008 at 09:39

Serious ST7 Assembler BUG

[fggnrc]

Posted on June 02, 2008 at 07:43

When I was debugging my code, I found a serious ST7 Assembler bug.

This STMicroelectronics assembler v4.49 bug deals with label constants. Here an excerpt of the assembler listing: 135 E8A4 AEEB LD X,#Avvio_uWeb.H 136 E8A6 A648 LD A,#Avvio_uWeb.L 137 E8A8 81 RET where Avvio_uWeb is defined later 653 .Avvio_uWeb 654 EB48 CDE124 CALL DetectIdle If the listing was ok, the .sym file would contain an entry for Avvio_uWeb whose address should be $EB48. The .sym file however contains: 'rom' CS E310 main E86F c_MasterKey EB90 Avvio_uWeb To my surprise, the $EB48 is now $EB90 (and in the final .s19 too)! What went wrong? EtaPhi PS: My target is a ST7FLITE29 and I use the lastest version of ST Visual Develop (4.0.0)

[robertjamier9]

Posted on June 17, 2008 at 14:18

It might be a bug.

Please send code (or excerpt) showing the problem. RJ

[fggnrc]

Posted on June 18, 2008 at 05:27

Robert,

can you provide me your private address so that I can send you the whole project and keep it undisclosed? Thank you in advance, EtaPhi [ This message was edited by: EtaPhi on 18-06-2008 12:33 ]

[brian4]

Posted on June 18, 2008 at 08:41

Hi EtaPhi

Could you let us know (forum users) the results of this problem i.e. is it a bug or a coding issue? Helps us if we have a similar problem in what to look for! Re Brian

[robertjamier9]

Posted on June 18, 2008 at 09:02

Please send me the code at the following address

robert.jamier@st.com

[fggnrc]

Posted on June 18, 2008 at 09:14

Don't worry Brian,

I'm going to tell everyone the condition that triggers this bug, and how to work around it (with the help of Robert, of course). Just wait for a while... EtaPhi

[robertjamier9]

Posted on June 19, 2008 at 08:25

The code is correct but the absolute listing, which is generated after, is wrong.

Here is a case where the listing bug appears and how to get round it. The variable array1 is declared in one file and used in another. Its address is decremented and used as part of an operand. The array address (0x100) is two-byte long but the decremented address (0x99) is only one-byte long, leaving a possibility for optimization. mapping.asm segment byte at 100-17F 'ram1' file1.asm WORDS segment 'ram1' .array1 DS.b 32 file2.asm EXTERN array1.w segment 'rom' LD ({array1-1},X),A --> code generated for LD ({array1-1},X),A: - in executable: D700FF - in absolute listing: E7FF --> the assembler is called a second time but only to generate the absolute listing from the map file, and this time the code is optimized. Solution 1: To remove the bug, move the declaration of array1 from file1.asm to file2.asm file1.asm file2.asm WORDS segment 'ram1' .array1 DS.b 32 segment 'rom' LD ({array1-1},X),A --> code generated for ''LD ({array1-1},X),A'' in executable and listing: D700FF Solution 2: or better add address range for ram1 in file2.asm file1.asm file2.asm WORDS segment byte at 100-17F 'ram1' .array1 DS.b 32 segment 'rom' LD ({array1-1},X),A --> code generated for ''LD ({array1-1},X),A'' in executable and listing: E7FF

[fggnrc]

Posted on June 19, 2008 at 09:39

Robert,

I am very grateful to you for your help. It is nice to have this kind of support from ST! My best wishes EtaPhi