Error 71 ... Out of ROM, A segment or the program is too lar

[Jean FOUGERON]

Hi guys

I have to make some little changes in a program I wrote one year ago.
At this date I compiled with Ccsc.exe V 4.3.0.357 (30/11/2012) PCW V4.119 (PCH V4.140) and it worked
I still have a workstation with this configuration, and it still works on it ...

As world has turned since this date I now compile with Ccsc.exe V5.0.0.463 (28/06/2016) PCW 5.061 (PCH V5.061) on another workstation and ...

I get the error 71 :

[temtronic]

The PIC you're using has 'banks' of program memory and requires that functions and main() be located wholely within a single bank. IE: a function can't cross or be in 2 banks. Say the banks are 10KB in size and you have 2 functions of 4KB each. 2 of them fit into a bank fine(2 X4=8) with some space left over but 3 will NOT fit(3 x 4=12), the 3rd function would have to overlap or cross or occupy 2 banks and that's NOT allowed.
One possible way to fix this is to rearrange the order of your functions and main() so that the compiler might get better use of the banks.
If that doesn't work, options include using a PIC with more memory or re-coding to maximize space. Since this is an existing project, hopefully you can re-code or rearrange existing code to get it to work.

Jay

[Jean FOUGERON]

Thanks for your quick answer temtronic

I think I understand what you write, but ...
In this case, the same PIC18F2220 compiled on the old workstation works, and on the new one does not !!!
It is the same panel that I move from one to the other, I hope the banks have not changed during the transfer.

If I increase memory (I put a PIC18F2520 = 16384 bytes iso 4096 bytes) I obtain exactly the same : it works on the old compiler and not on the new one.

I find it curious, not you ?

[gaugeguy]

With the newer version there have been udpates and fixes causing the assembly code size to increase just enough to not fit within the banking limitiations.

[Jean FOUGERON]

[jeremiah]

No, he is talking about the code can increase past the bank size. IIRC that's around 256 bytes per bank? not 100% sure but your data sheet should say.

You need to get your function size down I think. Maybe break it up into smaller functions?

EDIT:
see https://www.ccsinfo.com/forum/viewtopic.php?t=40257&highlight=bank+functions

[PCM programmer]

Are you using a bootloader with #org statements ? Did those #org
statements come from a CCS example file available for vs. 4.119 ?
They might not work with the larger code size in the modern compiler.

Post your #org statements.

[Jean FOUGERON]

The function which seems too large for it is the following (it is the one the error 71 mentions)

In my mind, it is not very long, and not so easy to split off
Why the V5.061 makes code larger than V4.119 ? Have they communicate on that ?

[Jean FOUGERON]

And if I clearly empty this function (mark inside as /* ... */) another one appears :

[Ttelmah]

You are fractionally missing the point here.

It's a 'blocks into hole' puzzle. The compiler tells you which one it can't fit, but the problem is almost certainly caused by one of the ones it has already put into the space. Imagine you have two boxes to fit on a shelf. Shelf is 1m long, and one box is 800mm long, and the other 250mm long. You put the 800mm box on the shelf, and then find the 250mm one won't fit. However the real problem is the 800mm one....

You can almost certainly get V5 to actually fit the code, if it did go in with V4, by compiling with the option (near the top of your source file):

#OPT compress

However this is fractionally dangerous. The reason V5 code is at times slightly larger, is that CCS have added more internal error checking to a lot of the functions. The compress option turns some of this off, and is less well tested code.

The real problem is that somewhere you have two of more large pieces of code, that are 'monolithic', and these are tending to block other items from fitting. It's down to programming 'style'. Keeping function sizes slightly smaller, allows much easier packing by the code.

[Jean FOUGERON]

[temtronic]

OK, going back to your original post, if v4.xyz worked WHY bother upgrading to v5.abc ? Obviously v4 was suitable for your PIC, perhaps you can explain why you upgraded?

I don't know how the 'optimize' feature may work but I do know that if YOU reorganize the functions, it might actually compile. I've seen it in the past where functions A,B,C would not compile but 'cut and paste' as A,C,B and it compiled just fine.

If you look at the disassembled listing ,you'll see the start and ending addresses for each function.Simply use a 'hex' calculator to subtract start from end and you'll know the size of the function. There's probably a magic bullet to choose this in MPLAB but I'm old school, like to dump listings and see what's going on...

Jay

[Ttelmah]

Lets make some further comments.

It is important to understand what is actually involved here. The PIC program memory, is not one large 'lump' of memory, it is instead for certain things treated like a book with pages. Your code is also in sections. A subroutine is a 'section' (effectively a paragraphs). Now a single part of a program (routine), can only work inside one page. (So in publishing terms, 'widow' lines must not exist).
So you have loads of 'paragraphs' and 'pages', and the compiler then tries to fit combinations of the latter in the former. The more the code is split up, the better the packing it can do. If you have no paragraph that is over half a page long, and most are much smaller, the compiler can look through all the different size pieces you have, and fit things in.

However we then come to V5, versus V4. There are two differences here. The first is that V5, in some places does try to generate 'safer' code, and this can cost a little on size. However the changes for this are small. The other though is that by default, V5, is optimised for speed, rather than for code size. As such, it will 'inline' more code by default.

What does 'inline' mean?.

A subroutine, can be generated in two ways. One is 'inline', and the other 'separate'. With the 'inline' version, the whole of a routine, is included 'inside' the calling code. With the 'separate' version, instead the routine is placed elsewhere, and called. The downside of the former, is that it prevents splitting up across pages, and can result in bulkier code. It's plus, is that it is faster, and involves less actual data movements. The _default_ action with V5, is to put routines which are small, and not called from many locations 'inline'.

So, when laying out code, think what routines do not matter if it takes a tiny bit longer to call, and mark these yourself, as #separate. Try to avoid large routines. If you have something doing a series of different sequences of operations, then consider whether each of these sequences could instead be moved to separate routines. A search here will find notes about how to do this, from literally hundreds of threads. It is a fundamental part of writing code for the PIC (particularly the older PIC's).
For comparison, the page size on most PIC16's, is 2K words. So a PIC with 16K of ROM (8K words), will have this split into four pieces. However on a PIC18, the memory is generally no longer paged (there are paging limitations that appear over 64K).

However I must also go back to PCM_programmer's question about whether you are using a bootloader?. The error being reported, appears to show the compiler behaving as if it is being excluded from some areas of the memory. Also there is a 'nasty', in trying to use I2C, both inside and outside an interrupt.....

[Jean FOUGERON]

[Jean FOUGERON]