Bootloader (loader.c) troubles...

[tedlarson]

I used the CCS bootloader sample, loader.c to make a simple boot loader for a PIC18F252. It seems to work very well when working with a toy/example program.

I went and tried to retrofit an existing (large) program with it, and immediately ran into trouble.

real_load_program
Seg 7C0A-7FFE, 033E left, need 0340
Seg 0000-0002, 0000 left, need 0340
Seg 0004-0006, 0004 left, need 0340
Seg 0008-00A2, 0000 left, need 0340

load_program

When I remove the "load.c" from my include list, I have 50% of my ROM free on the device, so I suspect that an individual segment is overflowing. I have gone through and used the #segment directive on all my functions, but it still doesn't seem to break things up enough. Does anyone have any suggestions on things I can do to get around the problem?

Thanks,

- Ted

[Mark]

I hope you meant #separate. Look at the lst file and the functions and see which ones are really large. Take those and break them up into smaller functions.

[tedlarson]

Whew!

After lots of looking at the list file, and breaking things up more....still no luck. Then, I started commenting things out until it would compile.

I isolated the problem to the following.
I have two global arrays in the program:

long vlist[25];
int vstat[25];

I notice that when I reduce the array size to something small....I suddenly can compile. I have a feeling that the compiler is trying to shove these into the same segment as the loader and having trouble. How can I move these out to somewhere else in memory, so they won't get in the way?

Thanks,

-Ted

[Mark]

Those are ram based and the problem you are having is rom shortage. sometimes moving variables around reduces the code size due to the bank switching instructions.

[tedlarson]

[tedlarson]

Ok....CCS tech support replied with an answer to the problem. I thought I would post my results, so the next guy who has the same trouble will know what to do.

LOADER_SIZE is incorrect for the PCH compiler.
It is too small. Currently I am using 0x41F
and it seems to all work now....although that value was
obtained by trial and error.

The next problem I am having is, when using it on a PIC16F876, it sucks up 50% of the available ram. Sooo...I am stuck again, with a different problem now.

Anyone out there know the answer to this one?

Thanks,

- Ted

[Mark]

Do you have