Hi, I have inherited a project, with no handover, and little documentation, so am in a spot of bother, as I haven't done embedded work for 15 years! My question is a bit vague, but is as specific as I can make it at present.
Question - does moving to a newer compiler/linker version necessitate any reworking of the source code?
Background - I have a uVision project with a 80C51 target. I have the old obj, hex, compiler/linker output files, from which I can verify that I am using the same build parameters.
The old working hex is 87477 bytes, and was built from:
C51 COMPILER V7.50 MACRO ASSEMBLER A51 V7.10 BL51 BANKED LINKER/LOCATER V5.12
My recompiled hex is 87619 bytes, and was built from:
C51 COMPILER V7.05 MACRO ASSEMBLER A51 V7.04a BL51 BANKED LINKER/LOCATER V5.03
My newly built version runs, and identifies itself as the correct version, on startup, but the serial comms is not functioning as expected, and the chip does not identify itself correctly to the Windows monitor application. My obj and hex differ slightly in size. Needless to say, I don't have the older compiler.
Further info. Extract from previous working build
C51 COMPILER V7.05, COMPILATION OF MODULE MAIN OBJECT MODULE PLACED IN MAIN.OBJ COMPILER INVOKED BY: C:\Keil\C51\BIN\C51.EXE MAIN.C LARGE BROWSE ORDER DEBUG OBJECTEXTEND MODULE INFORMATION: STATIC OVERLAYABLE CODE SIZE = 1088 ---- CONSTANT SIZE = ---- ---- XDATA SIZE = ---- 129 PDATA SIZE = ---- ---- DATA SIZE = ---- ---- IDATA SIZE = ---- ---- BIT SIZE = ---- ---- END OF MODULE INFORMATION. ---------------------------------------------------------- MACRO ASSEMBLER A51 V7.04a OBJECT MODULE PLACED IN hw_mi.OBJ ASSEMBLER INVOKED BY: C:\Keil\C51\BIN\A51.EXE hw_mi.src PR(.\hw_mi.ls1) EP DEBUG LOC OBJ LINE SOURCE 1 ; .\hw_mi.SRC generated from: hw_mi.c 2 ; COMPILER INVOKED BY: 3 ; C:\Keil\C51\BIN\C51.EXE hw_mi.c LARGE BROWSE ORDER DEBUG OBJECTEXTEND SRC(.\hw_mi.SRC) ---------------------------------------------------------- BL51 BANKED LINKER/LOCATER V5.03, INVOKED BY: C:\KEIL\C51\BIN\BL51.EXE VAR_DEF.obj, com.obj, disp_op.obj, entry.obj, hw_mi.obj, INIT.obj, MAIN.obj, MIDNIGHT.obj, OP_D >> ISW.obj, OP_FILLW.obj, OP_LOADW.obj, OP_MIX.obj, op_prep.obj, op_run.obj, OP_TRANS.obj, OP_WAIT.obj, UTILS.obj TO MI3 >> 21 RAMSIZE (256) XDATA (0X0100-0XFFFF) MEMORY MODEL: LARGE WITH FLOATING POINT ARITHMETIC . Program Size: data=216.0 xdata=60178 code=30433 LINK/LOCATE RUN COMPLETE. 2 WARNING(S), 0 ERROR(S)
Extract from my build
C51 COMPILER V7.50, COMPILATION OF MODULE MAIN OBJECT MODULE PLACED IN MAIN.OBJ COMPILER INVOKED BY: C:\Keil\C51\BIN\C51.EXE MAIN.C LARGE BROWSE ORDER DEBUG OBJECTEXTEND MODULE INFORMATION: STATIC OVERLAYABLE CODE SIZE = 1087 ---- CONSTANT SIZE = ---- ---- XDATA SIZE = ---- 129 PDATA SIZE = ---- ---- DATA SIZE = ---- ---- IDATA SIZE = ---- ---- BIT SIZE = ---- ---- END OF MODULE INFORMATION. ----------------------------------------------------------- MACRO ASSEMBLER A51 V7.10 OBJECT MODULE PLACED IN hw_mi.OBJ ASSEMBLER INVOKED BY: C:\Keil\C51\BIN\A51.EXE hw_mi.src PR(.\hw_mi.ls1) EP DEBUG LOC OBJ LINE SOURCE 1 ; .\hw_mi.SRC generated from: hw_mi.c 2 ; COMPILER INVOKED BY: 3 ; C:\Keil\C51\BIN\C51.EXE hw_mi.c LARGE BROWSE ORDER DEBUG OBJECTEXTEND SRC(.\hw_mi.SRC) ---------------------------------------------------------- BL51 BANKED LINKER/LOCATER V5.12, INVOKED BY: C:\KEIL\C51\BIN\BL51.EXE VAR_DEF.obj, com.obj, disp_op.obj, entry.obj, hw_mi.obj, INIT.obj, MAIN.obj, MIDNIGHT.obj, OP_D >> ISW.obj, OP_FILLW.obj, OP_LOADW.obj, OP_MIX.obj, op_prep.obj, op_run.obj, OP_TRANS.obj, OP_WAIT.obj, UTILS.obj TO MI3 >> 21 RAMSIZE (256) XDATA (0X0100-0XFFFF) MEMORY MODEL: LARGE WITH FLOATING POINT ARITHMETIC . Program Size: data=216.0 xdata=60178 code=30491 LINK/LOCATE RUN COMPLETE. 2 WARNING(S), 0 ERROR(S)
Many thanks, Nigel Frost
Thanks, this is very helpful. Firstly, you are quite right to spot that I have the compiler versions the wrong way round in my original question. At the time of asking, I only had the later version of the toolchain, and the list, map, obj and hex files from the previous build. This is a job for a small private firm, and they have no source control, etc. Following on from both replies, I realised that I had to get hold of the earlier tool chain version, as a starting point. I managed to get this from the Keil supplier, and I now have a working controller. I shall later follow your suggestion, and compare output files between Keil versions, and find out what code is causing the discrepancy, as this does suggest a vulnerability in the code. Thanks to both of you, I consider my question answered!