Hi, I have 2 sections of code, each uses many of the others files. One compiles/assembles, the other does not do so without frightening warnings. I feel that I must resolve these warnings. I have Read The Fine Manual (as some support people no doubt say to do), and I have only one CREG statement, that is the only code statement that has an "AT 0", and in fact the only use of an AT construct in the entire code. (I feel that I should have an explicit NOOVERLAY direction to the compiler, but I can not find my notes and can not find that in the manual.) I wish that the linker could tell me where it found those match ups (what files they came from, or what module names they have. Linker is silent on things that it knows. Also wishlist: a help file that will give remedys for common and even uncommon problems: a error section that would tell what to look for when the error occurs. Actually there is this, or a first cut attempt at this for the Compiler. Where is this for the linker? So I do not know what to look for, nor what the common things to do for this error are. I have reviewed my settings for the second project target. In Misc Controls part of L51 Misc, it is blank. Should it be? And where in the manual is there a place to tell me what could go in the L51 Misc box? Error messages and *.m51 output follow. * * * * * * * C O D E M E M O R Y * * * * * * * CODE 0000H 00DEH ABSOLUTE * OVERLAP * CODE 0000H 0034H ABSOLUTE * OVERLAP * CODE 0000H 000EH ABSOLUTE ... ... *** WARNING L5: CODE SPACE MEMORY OVERLAP FROM: 0000H TO: 00DDH *** WARNING L5: CODE SPACE MEMORY OVERLAP FROM: 0000H TO: 00DDH
Are these by change 2 or more interrupt handlers overlapping?
One section is the interrupt handler vector table. That is the one at the absolute address. I have not a clue for what the other sections are, but it might be that they are ordinary code. How can I tell? Where should they be? What should I look for? I am also noticing that the BL51 linker is being used, and I do not see an option to turn this off. I assume that I want to turn the banking linker off if I do not have nor want banking. John "Sean" Cleary
one line is 0000h and listed (by the linker) in the start of the code near the boot module. The others are in the LCD and the LL_Flash modules, and I do not think that these are the interrupt routines, but I will check further. Sean
the options on the two projects that share almost all the same code are different: RemoteVS_HH (this one has the trouble) >> bj TO .\Objects\Remote PRINT (.\Listings\Remote.m51) IXREF RAMSIZE (256) DISABLEWARNING (16, 10) CODE (0X0000-0XFFFF) XDATA (0X0000-0X7FFF) handheld >> bj TO .\Objects\HandHeld PRINT (.\Listings\HandHeld.m51) IXREF (NOGENERATED, NOLIBRARIES) RAMSIZE (256) NOOVERLAY CODE (0X0000-0XFFFF) XDATA (0X0000-0X7FFF)
I changed things around so that both have the same options: IXREF RAMSIZE (256) NOOVERLAY CODE (0X0000-0XFFFF) XDATA (0X0000-0X7FFF) and I still get the problem.
I have tracked the 0 based modules. I can not find anything that would cause these modules to be zero based. In one case the line that is said to be zero based is in the middle of the file!?! your help is needed and wanted. Sean
1. Leave overlay ON, unless you must use recursive functions or reentrantcy. 2. Disable ANSI integer promotion. 3. Don't mix C and assembly until you are an expert with 8051 assembly and C51's stack frame conventions. 4. The linker will use empty code space in the vector area if you do not define any ISR's to be placed there. This is fine unless you enable an unwanted interrupt by mistake. 5. You always want the banking linker (BL51.EXE) since it is the linker now, it just supports banking if you choose to do banking. 6. Enable all the linker's output options and generate a map file, then send me the map file if you wish. - Mark
This problem was a hard one. The orgs and CREGS and such were in order. But I had put a whole bunch of $IF (Is_HandHeld) in the code and then ran it with Is_Remote defined instead of Is_handheld. The asm style ifdef killed a few of " ASM_CODE SEGMENT CODE RSEG ASM_CODE ", and the following code did not know what segment it was in. So, as per Intel style assemblers, and totally unknown to me, it started another CODE segment at zero. It did not announce that it had done so in a conventional way, but the linker listing had these two zero based line numbers, one in one file and one in another. But I could not understand why a code segment would (re-)start in the middle of a file. Now I know. With great thanks to both Mark Olson who supplied answers and suggestions and helped me in many ways, and most especially to John W.(in Dallas) who stayed until 7pm (Late!) to help find and solve this problem. Sean