PCWH ROM used > 50K and program stops workng !

[Hans Wedemeyer]

My code stops working whenever ROM used goes above 49-50 K

Here is an example for PIC18F6720 when the code gets this large, all bets are off...

CCS PCH C Compiler, Version 3.202, 21503

Filename: H:\Picc\Projects\Version2\V2.LST

ROM used: 52124 bytes (40%)
Largest free fragment is 65536
RAM used: 2174 (57%) at main() level
2615 (68%) worst case
Stack: 11 worst case (10 in main + 1 for interrupts)

This code is made up of known tested code from smaller test programs.

Has anyone else had this problem with PCWH ?

[cfernandez]

I have the same problem in PIC18F8720, and I put the 3.200, try with this version.

[Hans Wedemeyer]

[cfernandez]

Not, and you?. You contact the technical support?.

Put the older version 3.200 and try your program with this, and tell me if work. My application use the 82% from 18F8720 and work fine.

Tell me if you found the problem or solution.

[Guest]

Hans,
I use V3.191 because it is the most stable version right now
Additionally you can play with #opt 10 in this version.
Some comments about 18F6720 (I use it in the last 4 months):
1. There must be something wrong with GOTO/BRA addresses in some case of boudaries. IME if my growing-up code stops working then the opposite state of the #opt 10 line (active or commented out) does the work. Yesterday I had to comment out the opt line after inserting a simple putchar() (!).
2. There is a problem about RAM addressing. I am not sure whether it is a silicon error or a compiler feature. Keep your "simple" variables (global and local char, int, etc.) below 0x0100 RAM address. Check the symbol file for it. Move your arrays, structs, etc. to 0x0300+ address range using #locate directive.

[cfernandez]

Invitado,

I see the alert from technical support that the 3.191 is more stable, but I test my code with the 3.200 and work very good, and I use the #opt 10 and my code reduce 2% compare with the 3.191, this good!!!.

With the 3.202 I see that the first goto is wrong, my code not execute nothing!!!.

I wait for a new version.

Best Regards,

[TSchultz]

Be a bit carefull with the whole PIC18Fxx20 line of chips. There have been many erattas on these. I was bitten by one of these, which in my opinion the chips should have been recalled. Rev C silicon may corrupt return values with "certain code combinations". Microchip cannot predict when this will happen. It is mostly a problem if operating faster than 8MHz.

I had no end of strange issues where code that seemed to work had odd bugs after making simple changes. After moving to A4 silicon these strange issues seemed to go away, this chip was much more stable.

This problem is not unique to the CCS compiler guys I know running the HiTech compiler encountered the same issues.

Not sure if this is what is happening but you may want to suspect the silicon. Microchip is still shipping the Rev C silcon. We had explicitly request the A4 silicon in order be guaranteed to get it.

[Guest]