_entry_scn error on building

[mprikril]

I am attempting to build Kevin's code with the streamlined camera program and I get an error:

'_entry_scn' type is non-overlay and absolure but occurs in more than one input file.

This has come up before as noted in this closed thread: http://www.chiefdelphi.com/forums/sh...ght=_entry_scn but I'm not entirely sure if I know what to do to fix it - as it seems like it shouldn't happen

Has anyone else run into this?

Thanks

[Mark McLeod]

Are you compiling Kevin's original code without any changes of your own?
If you've changed any files in the project which ones are they and what did you change?

[mprikril]

It was entirely Kevin's code. I had not changed a thing.

In the thread that was closed that I mentioned above, the user just tried again with a fresh download of Kevin's code. I downloaded his code again and tried, and it built with no errors. So we're back in business - or rather, we're at step 2 of 1000 - but you get the idea

That fact that it works now is odd, but not entirely unexpected.

[kiettyyyy]

Did you try to do a "Rebuild-all"? That is the button next to the build button.
Worked for me

Try that

Cheers!

[Alan Anderson]

That sort of error seems to be common when you change project directories and don't do a "clean" make. It looks like MPLAB keeps some information around about the previous project and tries to link both the old and new object files.

I believe it always goes away if you "build all" instead of just doing a normal fast compile of only the changed files, or if you delete all the intermediate files before compiling.

[teh_pwnerer795]

are u sure u arent calling any files like this??

#include camera.c

because that can cause a major problem...

do it like this instead

#include camera.h

also i had this problem once... sometimes if u uninstall MPLAB and reinstall it... it sometimes works that waay...

[Roger]

This is my problem too, but whatever has been suggested above and in many other places doesn't cure my woes. I've even taken the code from a "good" code" subdirectory to a 2nd computer and matched up all the options side by side. Everything matches (except see below for $(INCDIR)).

As Alan Anderson says, I copied a subdirectory of good code to another directory. After all, you want to be able to fall back to good code if you mess up the newer code. If this can't be done MPLAB is a bit useless. I've always done "Build All", and as Alan suggests, I've tried the "Clean".

The only difference is the Include Path $(INCDIR) -- the good code had none in "Build Options" General. With none in the "bad" code, I get

C:\CODE\0601-SHOOTER\2007-01-14 TEST\camera.c:30:Error [1027] unable to locate 'stdio.h'

Adding a path C:\mcc18\h to $(INCDIR) gets me thru all the Executing's and stops at MPLINK with

Error - section '_entry_scn' type is non-overlay and absolute but occurs in more than one input file.

I suspect this is the problem, somehow duplicating includes, but how else does one locate stdio.h?

From the microchip.com forum (via Google), I've found this (lets see if I can do quotes):

It's the Linker complaining that: _entry_scn occurs in more than one input file.
_entry_scn is a label in the startup files (c018x.o)
This should only be added in the linker script at the "FILES".

You probaly have this included in somewhere else your project *.mcw which you shouldn't.

I'm not quite sure what the bolded part means (bolding mine). I'd ask there but that thread is a year old. I've only got the usual files in the .mcw -- the *.c and *.h, plus FRC_library_8722.lib and 18f8722.lkr. There are no #include *.c's -- it's the same code between the two subdirectories!

Any suggestions?

Roger.

PS-- At least I'm not getting an error regarding "Generate_Pwms(pwm13,pwm14,pwm15,pwm16);"!

[dcbrown]

Build all and look at the last line before MPLINK in the output window, is it similar/identical to the following:

Executing: "E:\mcc18\bin\mplink.exe" /l"C:\mcc18\lib" "C:\CPrj\2007\Default\18f8722.lkr" "C:\CPrj\2007\Default\main.o" "C:\CPrj\2007\Default\user_routines_fast.o" "C:\CPrj\2007\Default\user_SerialDrv.o" "C:\CPrj\2007\Default\ifi_startup.o" "C:\CPrj\2007\Default\ifi_utilities.o" "C:\CPrj\2007\Default\user_routines.o" "C:\CPrj\2007\Default\FRC_library_8722.lib" /m"FrcCode.map" /o"FrcCode.cof"

In your .mcw project window, find and double click the 18f8722.lkr file to open it. This is the linker file. In it should be the following near the top:

//FILES c018i.o
FILES clib.lib
FILES p18f8722.lib

This is what the "FILES" comment refers to. The libraries are pulled from $(LIBDIR), which you can find when you open Project -> Build Options -> Project and select "General" tab. Under the same view, verify that the "Linker-Script Path" which is located at the bottom of the window is blank (see attached figure) - otherwise the project could pull in the default linker file... which as we will get to shortly can cause this error.

NOTE: The ifi provided linker file is different from the default linker file that comes from Microchip - the ifi version has the c018i.o reference commented out. If the line is missing the '//', add them in and rebuild all. If the linker file is ok, take a close look at the "Executing... mplink..." line in the build output window. Is the project picking up the linker file from the project directory or from the Microchip default directory? Referencing the wrong one will cause the problem.

I changed my linker file by uncommenting the "FILES c018i.o" line as follows to force the error in my project:

FILES c018i.o
FILES clib.lib
FILES p18f8722.lib

The error message appears, as expected in this case:

Copyright (c) 2004 Microchip Technology Inc.
Error - section '_entry_scn' type is non-overlay and absolute but occurs in more than one input file.
Errors : 1

That's because the linker file is now the same as Microchip's which includes the entry section in c018i.o (you can see this in \mcc18\lkr directory).

So the error message is indicating that somewhere in the link procedure it is encountering multiple modules that are defining the _entry_scn, but it only wants one definition. See section 2.9.1.4 of the C18 user guide under reserved section names for a description of this reserved section. Hopefully you haven't attempted to create another section of this name. If you don't think so, then you didn't. You'd have to add pragma statements defining the section name.

I used mplib /t on the libraries, but they look clean. I then looked into the View -> Disassembly Listing of the project and found that this section is declared in ifi_startup.c:

27: #pragma code _entry_scn=RESET_VECTOR
28: void _entry (void)
29: {
30: _asm goto _startup _endasm
00800 EF9E GOTO 0x393c
00802 F01C NOP
31:
32: }
00804 0012 RETURN 0

Neither map or listing file will be generated if there are linker errors. So, if you want to trouble shoot this more you can change the ifi_startup.c temporarily by adding "#ifdef NEVER" just before the pragma statement in ifi_startup.c and adding an "#endif" at the end of that file.

#ifdef NEVER
#pragma code _entry_scn=RESET_VECTOR
void _entry (void)
{
_asm goto _startup _endasm

}
:
.
#endif

Rebuild all.

Now, View -> Disassembly Listing (this assumes it now builds without errors). In this file do a View->Find for _entry_scn - scroll up and you will find which file is definining this section. Now at least you know which file is causing the problem and you can figure out how the linker is getting this file.

In my example:

--- C:\mcc18\src\traditional\startup\c018i.c ---------------------------------------------------
1: /* $Id: c018i.c,v 1.3 2004/07/30 17:28:43 ConnerJ Exp $ */
2:
3: /* Copyright (c)1999 Microchip Technology */
4:
5: /* MPLAB-C18 startup code, including initialized data */
6:
7: /* external reference to the user's main routine */
8: extern void main (void);
9: /* prototype for the startup function */
10: void _entry (void);
11: void _startup (void);
12: /* prototype for the initialized data setup */
13: void _do_cinit (void);
14:
15: extern volatile near unsigned long short TBLPTR;
16: extern near unsigned FSR0;
17: extern near char FPFLAGS;
18: #define RND 6
19:
20: #pragma code _entry_scn=0x000000
21: void

If this doesn't help or there are still problems, then cut and paste the "Executing ... mplink... " line from the mplab output window so we can see what is being linked together.

AND DON'T FORGET to remove the #ifdef NEVER...#endif from the ifi_startup.c file when done troubleshooting!


Bud

[Roger]

Wow! dcbrown thanks for your answer. The "//FILES c018i.o" was the final link to success. I've gotten good builds on the "bad" code, a subdirectory copy of a good code, and even on a separate computer. I never even thought to look in 18f872.lkr, let alone think it was a text-readable file. Next step is PROGRAMMING!

I have only one possible nit to pick, in case others are following along.

Verify that the "Linker-Script Path" just below the $(LIBDIR) is blank...

Should that be $(LKRDIR)? The picture you have is what I did.

Again, many thanks!

Roger.

[dcbrown]

I have only one possible nit to pick, in case others are following along.

Verify that the "Linker-Script Path" just below the $(LIBDIR) is blank...

Should that be $(LKRDIR)? The picture you have is what I did.

Poor choice of english on my part. I'll go back and edit it.

What I MEANT to say (really!) was to reference the whole linker-script dialog section which is below the libdir dialog which I referenced earlier. It is confusing the way it is currently written - I'll change it.

Bud

[Roger]

I knew what you meant to say (I think), but it was mostly in case anyone else had the problem. Besides, I was following the pictures!

[Roger]

Okay, dcbrown (insert #$^#&(*$% smilie here) unfortunately I didn't have access to the robot when I built the code. In the IFIloader, when I open the .HEX code, it pops open with a small window with the message

Invalid Address : 0x20 (Correct Range : 0x800-0x7fff)

[OK]

Which, I am guessing, some part of the compiler is giving the wrong starting address. Now what?

[dcbrown]

In build output window, what does COFF to HEX file converison look like?

MP2HEX 3.90, COFF to HEX File Converter
Copyright (c) 2004 Microchip Technology Inc.
Errors : 0

In MpLab, File -> Open, select FrcCode.hex. Once open, it should look something like:

:020000040000FA
:060800008AEF1CF012005B
:020806001200DE
:06080800ECEF0DF0120000
:02080E00C250D6
.
.

But in yours the file has an error message? I haven't had any of these problems with the default code.... yet. Which IFI loader version are you using?