Strange memory errors on 18F65J10

[Axel]

Hi!
I've run into a problem using version 4.064 of the compiler. It would seem that I've reached some kind of limit for memory usage. I've got plenty of RAM and flash available but adding new variables makes the hardware enter a reset-loop, rebooting almost instantly after finishing a boot sequence. The problem occurs for global variables in both RAM and flash. I have a distinct feeling that I've managed to hit some kind of ceiling concerning global variables of any type. My questions are: Is there such a ceiling? If there is, why does it exist and can I get around it in some easy way? If a ceiling doesn't exist, is this a known compiler problem for which a fix exists?

Best regards,
Axel Lindholm

[aopg64]

Hi folks,

I've run into a similar problem on the 18F8722. I had been using V3.249 for a long time and every now and then I would compile something that failed to run. By altering a string length or rewriting the code area I was working on, the recompiled code would then run. The compiler was indicating 90% Flash and 100% RAM usage.

I upgraded to V4.065 as that is our latest version (I prefer to stay with an old stable version generally!) as my colleague has been using it successfully.

This version has the same problem. I assumed it was the 100% RAM utilisation. I rewrote to get 99% RAM, but the problem still occurs.

I then suspected the PM3 not programming correctly, so I tried an ICD2. Same problem. So it must be MPLAB/CCS compiler/CCS Plug-in related (I guess?)

Thanks in advance for any help in sorting this.

Nige
_________________
No comment! (Can't think of anything interesting to say!)

[FvM]

Hello,

I guess, it's advisable to keep your V3.xx compiler with existing products, if ever possible. Some things have been definitely changed in an incompatible way. Some changes may be small, as the address requirements with bootloader definitions. I also experienced that the RAM and ROM consumption has been apparently increased. This may serve a good purpose, but can also crash an existing application. I'll continue to try, if existing applications can be easily ported, but if any incompatibilities arise, there's a strict stop. The topic may be reviewed in one or two years, when the V4 has reached a certain maturity.

Regards,
Frank

[Axel]

Me and my colleague managed to temporarily fix this problem by changing all of our variables with ROM qualifiers to use a const qualifier instead. The const qualifier results in a different and more compact data alignment on the flash for us which solved our problem with unexplained resets.

However, a strange thing happened as a result of substituting ROM for const. While using the ROM qualifier MPLAB asserted that we had a 65% ROM usage and a 98% usage including unused fragments (this number was grabbed from the STA-file). With the const qualifier the ROM usage rocketed to 90% while the including-unused-fragments usage dropped to 92%. Because of the difference in alignment I can understand why the unused-fragments number dropped closer to the actual ROM usage but the million dollar question is why the ROM usage was raised with 25% from using a seemingly more compact representation.

Does anyone have an idea on whats going on? Does the compiler generate a lot of code overhead for const qualified variables or was the original 65% ROM usage indicated somehow incorrect?

A small footnote is that when getting an address to a const qualified array we had to break common sense and C semantics by putting an address-operator in front of the array name or it would read from the array instead of getting the address.

[Ttelmah]

When you use 'const', the compiler adds a little program in front of every block of stored values, to handle the retrieval of the values. So if you declare (say):

[Axel]

Thank you very much for explaining this Ttelmah! This bit of info really helped a lot in making some important design decisions for our project.

Best regards,
Axel Lindholm

[Axel]

Hi again, still wrestling the problem...