Hard to explain problem, CALL to random places

[Laurent Chouinard]

Not only is my problem hard to diagnose, but my project is quite big so sharing code here is problematic. I am still trying my luck out, in case someone could have insight, tips or ideas as to explain the behavior I am having.

I use 4.033 compiler, pic18f6722.

So, let's assume I have a main() function, lots of includes, lots of functions, lots of ram consumed (80% worst case!), and about 45% of the rom used.

This main function does a lot of things, and then something like this:

[Ttelmah]

First, look at the top of the list file generated. What does it show for the number of stack levels used?. If this is beyond the maximum supported by the chip, then this is the 'answer', and you need to reduce the 'depth' of the tree of subroutines. This is relatively unlikely on these larger chips (32 stack levels), but would be the most likely cause on a smaller chip.

Constant strings, are handled in a very 'non intuitive' way. They generate a program, which returns the required byte, according to a value passed representing the 'index'. So, when the string gets longer, so does the program. Is 'SuperFunction', called in multiple places?. If not, then the odds are, that it will be generated 'inline' (this is the default behaviour). If this is the case, then the extra bytes, may well be making 'main' itself grow. Now it is possible, that your code size, is reaching the point, where some routines are having to shift over above the FFFF - 10000 boundary. If so, then there can be a sudden 'jump' in code size involved, and new problems introduced, as previously working code fails to handle the extra address bit properly. If (for instance), you are handling interrupt code yourself, and not saving the extra address bit, then problems would appear at this point. You might want to try explicitly declaring Superfunction as 'separate', to see if this changes what happens.

Are you using external memory?. If so, there is an erratum, relating to the stack, which might well introduce problems. There is also one to do with certain instructions, resulting in registers geting the wrong value, which you might want to check with CCS, whether the fix is in place. Unfortunately, sometimes tiny changes in program size, can result in this sort of fault appearing, which makes diagnosis a pig...

Best Wishes

[Guest]

Ttelmah,

Here is the top of he LST file.

[Laurent Chouinard]

Weird forum, I was logged in 5 minutes ago and this posted as Guest. Oh well.

[Laurent Chouinard]

I was just reading the WIEGAND thread a few pixels below me, and someone mentioned that, compiler 4 is mostly alpha with the versions above 4.030 being "mostly usable". I was shocked! Why is this even public if it's not production quality? Damn.

So I grabbed 3.249, I changed the bit array I had to a byte array, and, well, no problem yet. I think i'll stick to v3 for ... ever.

[Ttelmah]

At the top of the group, there is a 'sticky thread' about V4. You will see a lot of posts...
The current V4 releases, have just started to become 'useable', and might be arguable as a reasonable 'beta' (except that several of the new features don't yet work...). However your problem is still 'typical', of something odd happening inside. If I was 'privately' paying for the support in the UK, I have felt on several occasions, that I could take CCS's suppliers to court over here, for not supplying a product 'of merchantable quality'. You will see several people who will always advise, that if you are having problems, and your chip is supported by 3.249, then try with this.
The sizes you have don't suggest anything directly, I'd guess at an internal table of some sort hitting a limit...
:(

Best Wishes

[Laurent Chouinard]

Damn it. Had I known v4 was a product in development not meant for production, I would not have used it. But no where did they ever mention "oh by the way, don't use version 4."

I have wished I could replace this compiler for another one many times over the last 4 years that I have been using it, but everytime we just reasoned that it would be more complicated to port the code of all our products to another compiler than it is to endure the bugs of this one.

I think that this event just convinced me otherwise, I will look into alternatives.

I mean of all the software I buy and use, I would assume that a COMPILER has to be the one that isn't buggy, right?

[Ttelmah]

All compilers have bugs.
I have three currently 'on report', with Microsoft, for their current C# compiler....
However, most of these are 'exotic', with the core parts working well. The problem with CCS, is that they have a truly appalling approach to beta releases, and sometimes introduce problems that even the most basic QA, should find.
When they launch a major 'new' compiler, what ships, is often not even a reasonable 'alpha' release. Historically, you can reckon on perhaps six months after 'release' for the first reasonably stable version. 'Old hands', know this well. V4, has taken longer than this.
Then, they provide new 'sub releases', apparently to fix issues bought to their attention, but without checking that the 'fix' has not introduced new problems.
Historically, the download site, always carries two versions, with the new one being effectively the current 'beta', and the older one, the 'last known good'.
Several people here, have repeatedly cried for three things:
1) Some form of indication of the untested status of rapidly released versions.
2) Use of a reasonable range of test programs 'in house', to verify that basic operations do work, before any version appears on the site.
3) Better listing of what is changed/fixed in each version.
The 'silly' thing is that they seem to fail to understand, that once a customer is lost, you are very unlikely to get them back, and 'mud sticks'. The latest release represented an amazing triumph of marketting over the code being ready, with the premature release, undoubtedly 'tainting' quite a few people's perception of the compiler, which will not do their business any good in the long term...

Best Wishes

[Jim Hearne]

Maybe not a great deal of help, but my current project on a 18LF6722 has the following stats.

[RossJ]

Hello Laurent,

I have just spent half the day debugging a problem which is likely the same as yours...

It appears to be a bug in the lookup table code generated for a switch statement. My guess is that when a switch statement contains more than a handful of cases (around 6-8?), instead of using the xor/btfs sequence, it uses a lookup table of addresses. This code is not visible in the .lst file, so you have to use mplab or similar to view the disassembly listing. Here is a faulty example:

[RossJ]

Hi again,

Further to my last post, it appears to be a new bug in 4.033. From the current version log...

[RossJ]

This problem is fixed in 4.034.