Multiple Compilation Problem?

[TAMA25]

Compiler: PCWH 5.110
Device: PIC18F57Q84
Use PICKIT4 and No debugger.

I am testing multiple file compilations because I need them for work.

I found that it did not work properly (LEDs did not light up) with LINK, so I compiled it in C without LINK and found that it works.
I also found that it works even if I stop including string.h and stdlib.h.

Comparing the list with the problematic state, the code in the main function is quite different and I think this is the cause of the problem.
The problem seems to occur when I pass main.o with string.h and stdlib.h included to LINKER.
Why does this happen?

(Translated by Deepl. Sorry if some parts are hard to read.)

[ main.c ]
----------
#include <18F57Q84.h>

#device ADC=12
#fuses NOWDT,NOPROTECT,NOLVP
#use delay(clock=64000000, crystal=16000000)

#byte PORTA = 0x04CE
#byte PORTB = 0x04CF
#byte PORTC = 0x04D0
#byte PORTD = 0x04D1
#byte PORTE = 0x04D2
#byte PORTF = 0x04D3
#use fast_io(A)
#use fast_io(B)
#use fast_io(C)
#use fast_io(D)
#use fast_io(E)
#use fast_io(F)

//#include <math.h>
//#include <stdlib.h>
#include <string.h>

void setup()
{
setup_oscillator(OSC_EXTOSC_PLL | OSC_CLK_DIV_BY_1 | OSC_PLL_ENABLED);
set_tris_a(0x30); // RA4,RA5 -input
set_tris_b(0x1f); // RB0-RB3 -input RB4 - CAN RX
set_tris_c(0x00);
set_tris_d(0xfd); // RD2-RD7 -input RD0 - SCI0 RX
set_tris_e(0x01); // RE0 -input
set_tris_f(0xf0); // RF4-RF7 -input
PORTA = 0;
PORTB = 0;
PORTC = 0;
PORTD = 0;
PORTE = 0;
PORTF = 0;
}

void main( void ){
setup();
while(1) {
PORTC = PORTB;
}
}
----------

[ build.bat ]( make project.hex and main.hex )
----------
"C:\Program Files (x86)\PICC\CCSC.exe" +FH +LN +STDOUT +EXPORT main.c
"C:\Program Files (x86)\PICC\CCSC.exe" +FH +EA +STDOUT -EW +PE +LN LINK="project.hex=main.o"
"C:\Program Files (x86)\PICC\CCSC.exe" +FH +LN +STDOUT main.c
----------

[ main.lst ](include string.h) -> work fine
----------
.................... void main( void ){
000A8: CLRF 4F8
000AA: BCF 4D6.5
000AC: BSF 507.7
000AE: CLRF xB0
000B0: CLRF xAF
000B2: CLRF xB3
000B4: CLRF xB1
000B6: MOVLW 20
000B8: MOVWF xAD
000BA: MOVLB 4
000BC: CLRF x00
000BE: CLRF x08
000C0: CLRF x10
000C2: CLRF x18
000C4: CLRF x20
000C6: CLRF x28
000C8: MOVLB 0
000CA: CLRF x71
000CC: CLRF x72
000CE: CLRF x73
000D0: CLRF x70
000D2: CLRF x75
000D4: CLRF x76
000D6: CLRF x77
000D8: CLRF x74
000DA: CLRF 51B
000DC: CLRF 51C
....................
.................... setup();
000DE: BRA 006E
....................
.................... while(1) {
.................... PORTC = PORTB;
000E0: MOVFF 4CF,4D0
000E4: BRA 00E0
.................... }
.................... }
000E6: SLEEP
----------

[ project.lst ](include string.h) -> Didnot work
----------
.................... void main( void ){
000A8: CLRF 4F8
000AA: BCF 4D6.5
000AC: BSF 507.7
000AE: CLRF xB0
000B0: CLRF xAF
000B2: CLRF xB3
000B4: CLRF xB1
000B6: MOVLW 20
000B8: MOVWF xAD
000BA: BRA 00C6
000BC: DATA 08,40
000BE: DATA 70,00
000C0: DATA 02,05
000C2: DATA 1B,00
000C4: DATA 00,00
000C6: MOVLW 00
000C8: MOVWF 4F8
000CA: MOVLW 00
000CC: MOVWF 4F7
000CE: MOVLW BC
000D0: MOVWF 4F6
000D2: TBLRD*+
000D4: MOVF 4F5,W
000D6: MOVWF 500
000D8: XORLW 00
000DA: BZ 0102
000DC: TBLRD*+
000DE: MOVF 4F5,W
000E0: MOVWF 501
000E2: BTFSC 4E8.7
000E4: BRA 00F0
000E6: ANDLW 3F
000E8: MOVWF 4EA
000EA: TBLRD*+
000EC: MOVFF 4F5,4E9
000F0: BTFSC 501.6
000F2: TBLRD*+
000F4: BTFSS 501.6
000F6: TBLRD*+
000F8: MOVFF 4F5,4EE
000FC: DCFSNZ 500,F
000FE: BRA 00D2
00100: BRA 00F4
00102: CLRF 4F8
....................
.................... setup();
00104: BRA 006E
....................
.................... while(1) {
.................... PORTC = PORTB;
00106: MOVFF 4CF,4D0
0010A: BRA 0106
.................... }
.................... }
....................
0010C: SLEEP
----------

[Ttelmah]

Learn to use the code buttons...

The include files are not 'passed'.
What is passed in the MCU, is only the functions it is told to export. Nothing
else.
If a second file wants to use stdlib.h and string.h, then these have to be
included in _it's_ compilation.
Look at the example.
This shows how to export the functions from each section, and then how to
import these into a final master compilation.

The example is mcu.zip in the examples directory. Expand this and look
at how it is done.

Note importantly that _each_ part of the project has to include the 'master'
clock and fuse settings, and also any include files. #INCLUDE's like
stdlib and string, are _not_ exported in the built .o file.

You currently don't have anything putting the stuff together. Even though
you only have a single section, it still needs to have a final linking to
actually work.

[TAMA25]

Thanks, mr.Ttelmah.

I'll be careful to use the code button.

[Ttelmah]

The point is you seem to be trying to build a single file project. Key in
MCU, is 'Multiple'. I don't think the linker supports building just one element.
You need to have multiple units, and link these together. I just tried a
copy of your project, but put setup, into a separate setup.c with a
setup.h. I then told the linker to link main.o, and setup.o
It merrily compiled (with string.h included), and linked, and in the
MPLAB sim, the resulting program ran.

[TAMA25]

In the course of multi-file testing, I discovered something.

project.h

[TAMA25]

This is the result of the verification by combining a total of 6 o-files, although it is still short of the desired scale.

Up to optimization level 8 (+Y8), TBLRD does not appear in the assembly code at the head of main() and seems to work.
When +Y9 is specified or not specified, TBLRD appears and it does not work.

It's a mystery.

[Ttelmah]

There was a problem with one particular maths operation and optimisation
with 5.105 (in the 'known issues' section of the forum). Your compiler should
have this fixed. However it is likely that something specific about your code
is triggering something similar.

[Ttelmah]

OK.
That is repeatable, and does it even with the latest compiler.
You need to report this to CCS, since it is obviously an issue on this
chip at least (on a much older chip it doesn't seem to be doing this), when
using MCU's.
Send them these examples and hopefully they will have a fix soon.
Meantime run with the optimisation turned down.

[TAMA25]

Thank you for the advice.

I just tried it with the latest version of the compiler (5.113),
and it outputs the same assembly code as 5.110,
and the result of running it is the same.

I have reported this to CCS.
I will post again if there is progress.

[Ttelmah]

As I said "and does it even with the latest compiler".

Understand that MCU's with CCS, are really a bad idea. CCS was built as
a single pass compiler. Never designed to support linking. Working single
pass allows better optimisation, so most people never get involved with
trying to use MCU's. CCS added the capability a while ago, but for me it
has never worked 100%. Given how fast the compiler actually works,
compiling as a single entity, this is really the approach to use.
Now your phrasing at the start suggests that you have some specific need
for using MCU's. Difficult to really work out what this might be?.
Hopefully CCS will fix this issue for you, but do expect MCU's to still
have problems. They really are not the way to work with the CCS compiler.

[BrianF]

[gaugeguy]

Having multiple C files is quite normal and is not the same as MCU

[newguy]

[Ttelmah]

Dead right.
Your approach is pretty much what every one of the experienced users does.
Perhaps a file with the CPU setup, fuses & peripherals, then one with
global variables, then all the library includes, and then the files for each
section of the program (comms, memory, storage, different types of I/O,
etc. etc..). I often have a 'comments' file, included near the top, with details
of problems found with particular chips, and versions, with notes of what
changed. Also says what compiler was used. Makes coming 'back' to code
in many years time, vastly easier. Current project uses 3*DsPIC's, and the
code for each has perhaps 20 files. Compiles to just over 500KB of code
in total. One is handling a particular sensor, with a lot of nasty maths
(has to use logs and powers in the calculation of the polynomial to correct
the sensor). Second one handles the graphic display, and the main one
handles the user interface, storage, I/O, etc. etc..

[jeremiah]