Use 18F452 If Ram more than 50% the variables are corupted

[johanpret]

Hi All,
I Use the 18F452. If Ram used are more than 50\% the variables are corupted. If I use less than the 50\% ram everyting is fine. As soon as I go over 50 \% then the variables are corupted. The variables that are corupted are unsigned long int that keep analog readings.

Johan Pretorius
___________________________
This message was ported from CCS's old forum
Original Post ID: 144515016

[R.J.Hamlett]

:=Hi All,
:=I Use the 18F452. If Ram used are more than 50\% the variables are corupted. If I use less than the 50\% ram everyting is fine. As soon as I go over 50 \% then the variables are corupted. The variables that are corupted are unsigned long int that keep analog readings.
:=
:=Johan Pretorius

What version compiler?.
I am running a project at present on the 18F452, which uses over 93\% RAM, and about the same on ROM, and have seen no problems of this sort. _But_, there were a lot of problems before about 3.100, and even since then some versions have made some odd problems re-appear...
There was a problem in the past that caused data corruption, if certain table operations were used (this is a hardware problem with the chip), and the modern code does correct for this, but to do so, has to disable interrupts more than is perhaps 'desirable'.

Best Wishes
___________________________
This message was ported from CCS's old forum
Original Post ID: 144515017

[johanpret]

I Use version 3.158 I change only one of my array sizes from 250 to 240 (Less than 50 \% Ram) and the problem is gone.I supose you don't need the #device= *=16 for the pic18 series.

Cheers

Johan

:=:=Hi All,
:=:=I Use the 18F452. If Ram used are more than 50\% the variables are corupted. If I use less than the 50\% ram everyting is fine. As soon as I go over 50 \% then the variables are corupted. The variables that are corupted are unsigned long int that keep analog readings.
:=:=
:=:=Johan Pretorius
:=
:=What version compiler?.
:=I am running a project at present on the 18F452, which uses over 93\% RAM, and about the same on ROM, and have seen no problems of this sort. _But_, there were a lot of problems before about 3.100, and even since then some versions have made some odd problems re-appear...
:=There was a problem in the past that caused data corruption, if certain table operations were used (this is a hardware problem with the chip), and the modern code does correct for this, but to do so, has to disable interrupts more than is perhaps 'desirable'.
:=
:=Best Wishes
___________________________
This message was ported from CCS's old forum
Original Post ID: 144515028

[R.J.Hamlett]

:=I Use version 3.158 I change only one of my array sizes from 250 to 240 (Less than 50 \% Ram) and the problem is gone.I supose you don't need the #device= *=16 for the pic18 series.
:=
:=Cheers
:=
:=Johan
There were I think quite a few 'oddities' initroduced by 3.158. I must admit I never tried it. I have several versions running at present (including 3.100, and 3.160), and neither of these are displaying this problem.
My code doesn't have *=16 in this case (should only be necessary on the older chips).
Are you sure about your 'ram size' involved?. What is the array made of?. It sounds (if it is using about 50\% RAM), as if the array must be made of elements holding about 3 bytes each.
I would suspect the problem is not because of the memory size involved, but because of the nature of the array (as a single 'lump'). The compiler needs some 'scratch' storage locations, and may well be having problems dealing with a single entity this size. I would expect that if you split the array into two 'halves', you would find that the problem disappears. On the older chips, arrays were limited to a maximum of 128 bytes, and though this limit has disappeared on the 18F, I'd still be very 'wary' of using an array this large, without special handling.
I have got a single massive array (499 bytes long), used as part of my 'message' handling, and I do this myself, by reserving the memory, and storing pointers to the reserved area:

#RESERVE 0x400:0x5F3
char *general = (int *)0x400;
char *msg[52];

Then I put into the 'msg' array, the addresses needed in the 'general' array, when the correct data is prepared. Historically, I had problems with the earlier compilers handling arrays this large, so ended up 'coding round' this, and have retained this with the later compilers (one 'early oddity', is illustrated by the combination of a variable pointing to a 'char', yet being cast as an integer pointer - this fixed a problem with an earlier compiler...).
So if you need to handle the array as a single large 'lump', I'd manually reserve the storage, using a high memory page (or multiple pages), and see if this avoids your problem.
Use #reserve, to prevent the compiler accessing (say) 0x300 to 0x5FF, and the #locate your array here, and see what happens.

Best Wishes

:=:=:=Hi All,
:=:=:=I Use the 18F452. If Ram used are more than 50\% the variables are corupted. If I use less than the 50\% ram everyting is fine. As soon as I go over 50 \% then the variables are corupted. The variables that are corupted are unsigned long int that keep analog readings.
:=:=:=
:=:=:=Johan Pretorius
:=:=
:=:=What version compiler?.
:=:=I am running a project at present on the 18F452, which uses over 93\% RAM, and about the same on ROM, and have seen no problems of this sort. _But_, there were a lot of problems before about 3.100, and even since then some versions have made some odd problems re-appear...
:=:=There was a problem in the past that caused data corruption, if certain table operations were used (this is a hardware problem with the chip), and the modern code does correct for this, but to do so, has to disable interrupts more than is perhaps 'desirable'.
:=:=
:=:=Best Wishes
___________________________
This message was ported from CCS's old forum
Original Post ID: 144515043

[TSchultz]

<SNIP>
:=There were I think quite a few 'oddities' initroduced by 3.158. I must admit I never tried it. I have several versions running at present (including 3.100, and 3.160), and neither of these are displaying this problem.
<END SNIP>

I am still running version 3.142 as I have not renewed my maintenance, I will when I start another project using this compiler again and need some new bugs. I do think the compiler is quite stable now but I am still cautious, at least I could predict what was happening at the time with 3.142.

I did a design using the PIC18F452 and had some VERY strange math related problems. The program used a lot of arrays of structures. Each time I made small changes the errors would change, sometime the program ran fine, other I would get periodic calculation errors.

After spending a lot of time going throught the code I spent some time going through the memory map. I found places where some varaibles were at the same locations as those used by my arrays. If I forced the locations of mostly all the variables, especially all the arrays and other vars that had conflicting addresses, then my program run fine.

These problems seemed to be mostly at the end of arrays, where the last couple of bytes were corrupted by other variables. I was using approx. 75\% of RAM. These type problems got progressively worse as I used more RAM. It is a real pain to go through and manually force locations for all the variables, that is why I use the compiler.

I reported the problem but never heard anything. I just left the manual memory locations in place as everything worked fine that way. The program has been running continuously now since mid March and has had no "strange" errors.

I have since played around a bit to see what kinds of variables this happens but have not been able to come up with a consistant way to reproduce the problem all the time.

Regards
-Troy
___________________________
This message was ported from CCS's old forum
Original Post ID: 144515044

[R.J.Hamlett]

:=<SNIP>
:=:=There were I think quite a few 'oddities' initroduced by 3.158. I must admit I never tried it. I have several versions running at present (including 3.100, and 3.160), and neither of these are displaying this problem.
:=<END SNIP>
:=
:=I am still running version 3.142 as I have not renewed my maintenance, I will when I start another project using this compiler again and need some new bugs. I do think the compiler is quite stable now but I am still cautious, at least I could predict what was happening at the time with 3.142.
:=
:=I did a design using the PIC18F452 and had some VERY strange math related problems. The program used a lot of arrays of structures. Each time I made small changes the errors would change, sometime the program ran fine, other I would get periodic calculation errors.
:=
:=After spending a lot of time going throught the code I spent some time going through the memory map. I found places where some varaibles were at the same locations as those used by my arrays. If I forced the locations of mostly all the variables, especially all the arrays and other vars that had conflicting addresses, then my program run fine.
:=
:=These problems seemed to be mostly at the end of arrays, where the last couple of bytes were corrupted by other variables. I was using approx. 75\% of RAM. These type problems got progressively worse as I used more RAM. It is a real pain to go through and manually force locations for all the variables, that is why I use the compiler.
:=
:=I reported the problem but never heard anything. I just left the manual memory locations in place as everything worked fine that way. The program has been running continuously now since mid March and has had no "strange" errors.
:=
:=I have since played around a bit to see what kinds of variables this happens but have not been able to come up with a consistant way to reproduce the problem all the time.
:=
:=Regards
:=-Troy
There was a problem at about this time, with 'sizeof', sometimes returning incorrect data, for anything more complex than a normal variable. I'd suspect this is 'tied in' with this, since (obviously), if the size data is used internally to calculate the array length, it would lead to this sort of behaviour...
This fault was supposedly fixed, but it may be 're-appearing' in some specific cases. :-(

Best Wishes
___________________________
This message was ported from CCS's old forum
Original Post ID: 144515048

[jesse lackey]

I can tell you for a fact that const tables > ~250 bytes do not work due to compiler bugs prior to 3.143. The exact size that you run into a problem depended on where in memory the table started. I spent nearly 30 hours tracking this down, as the table I had was mp3 chip initialization code. I wanted to shoot everyone in the ccs QA dept. I'm not sure there is a QA dept.

This was (supposedly) fixed in 3.143. I wrote a C program to split my table into 200-byte pieces to avoid the bug, and haven't changed it back.

So look closely at code that accesses the arrays. Does the assembler make sense? Will it fail when crossing 256-byte boundaries? Does it use a byte instead of a word? If something quirky seems like a compiler bug, it often is.

Make a few more (small) arrays and init them to zero or something to go over the "magic" 50\% boundary. I bet it will work fine. Then increase your big array to 250, and it fails. Then look at the code that uses the array.

Good luck.
Jesse


:=I Use version 3.158 I change only one of my array sizes from 250 to 240 (Less than 50 \% Ram) and the problem is gone.I supose you don't need the #device= *=16 for the pic18 series.
:=
:=Cheers
:=
:=Johan
:=
:=:=:=Hi All,
:=:=:=I Use the 18F452. If Ram used are more than 50\% the variables are corupted. If I use less than the 50\% ram everyting is fine. As soon as I go over 50 \% then the variables are corupted. The variables that are corupted are unsigned long int that keep analog readings.
:=:=:=
:=:=:=Johan Pretorius
:=:=
:=:=What version compiler?.
:=:=I am running a project at present on the 18F452, which uses over 93\% RAM, and about the same on ROM, and have seen no problems of this sort. _But_, there were a lot of problems before about 3.100, and even since then some versions have made some odd problems re-appear...
:=:=There was a problem in the past that caused data corruption, if certain table operations were used (this is a hardware problem with the chip), and the modern code does correct for this, but to do so, has to disable interrupts more than is perhaps 'desirable'.
:=:=
:=:=Best Wishes
___________________________
This message was ported from CCS's old forum
Original Post ID: 144515081