CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug reports on this forum. Send them to support@ccsinfo.com

5.085 pic24 crashes using #device PSV=16 and CCS CAN library

 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
SergioMForster



Joined: 23 Jan 2019
Posts: 29
Location: Argentina

View user's profile Send private message

5.085 pic24 crashes using #device PSV=16 and CCS CAN library
PostPosted: Mon Apr 29, 2019 4:23 pm     Reply with quote

Due to a problem I am having with a project to which I have to add CAN I found an incompatibility between the CAN library <can-pic24.c> and the mode #device PSV=16

Simply making a new empty project, (I'm using PIC24EP512GU814), to which I add #include <can-pic24.c> in the c file, and #device PSV = 16 in the h file,

Compiling this project ends with the error "not enough RAM for all variables."

If I comment the line #device PSV = 16, it compiles without problems, and uses very little ram.

RAM used: 1124/53158 (2%) at main() level
1153/53158 (2%) worst case

If I leave the line #device PSV = 16 but I remove the #include <can-pic24.c> it also compiles without problems and uses even less ram.

RAM used: 97/30630 (0%) at main() level
97/30630 (0%) worst case

Is there any workaround to resolve this incompatibility?
Ttelmah



Joined: 11 Mar 2010
Posts: 19195

View user's profile Send private message

PostPosted: Tue Apr 30, 2019 7:10 am     Reply with quote

I'd doubt it.
Use the older compiler version, and report this to CCS.
You have the only 'work round', which is to not use PSV....

Quite a few PCD changes being documented on the latest compiler
revisions, so 'not surprised' that it is causing some issues. Sad
SergioMForster



Joined: 23 Jan 2019
Posts: 29
Location: Argentina

View user's profile Send private message

PostPosted: Tue Apr 30, 2019 8:51 am     Reply with quote

The problem had already appeared in the 5.082

I upgraded to 5,085 with the hope that this will resolve the issue

I already sent the case to CCS Support yesterday, but so far I had no response

Ttelmah, I'm very sorry I did not follow your wise advice not to use PSV in my projects

Obviously the PSV functionality, is not mature and is not well implemented in CCS and brings more problems than solutions
Ttelmah



Joined: 11 Mar 2010
Posts: 19195

View user's profile Send private message

PostPosted: Tue Apr 30, 2019 10:28 am     Reply with quote

PSV, was working quite well a few compiler versions ago. I started having
trouble after 5.081, and did report it to CCS, but none of the fixes they
supplied worked, so I went back to the older compilers. It looks as if
instead of getting better, things are getting worse here. Sad
They did not seem to be able to reproduce the actual issues I was seeing,
hopefully they have more luck now someone else is also having the
problems!...
Ttelmah



Joined: 11 Mar 2010
Posts: 19195

View user's profile Send private message

PostPosted: Wed May 01, 2019 1:41 am     Reply with quote

Interesting, just tried building the PCD CAN example, with PSV=16 set, and
was quite happy and built OK on PCD5.085. I also added a large 'const'
table to make PSV be actually used, and it still worked OK.
So something your code is doing is making the incompatibility happen.
Problem is (of course) going to be tracking down which exact part of the
code does this... Sad
SergioMForster



Joined: 23 Jan 2019
Posts: 29
Location: Argentina

View user's profile Send private message

PostPosted: Wed May 01, 2019 9:14 am     Reply with quote

Ttelmah, thank you for your comment.

Unfortunately I have to inform you that the tests were made with a completely empty project created with the wizard.

The only lines I added were the #include <can-pic24.c> (with this compiles without errors).

Then add the #device PSV = 16 and compile "Error: not enough RAM for all variables" appears.

Obviously it is a conflict of can-pic24.c from CCS with PSV mode.

The main.c
Code:
#include <main.h>
#include <can-pic24.c>

void main()
{

   while(TRUE)
   {
      //TODO: User Code
   }

}


The main.h
Code:
#include <24EP512GU814.h>
#device ICSP=1
#device PSV=16
#use delay(crystal=20000000)

#FUSES WDT                      //Watch Dog Timer
#FUSES WPRES32                  //Watch Dog Timer PreScalar 1:32
#FUSES WPOSTS1                  //Watch Dog Timer PostScalar 1:1
#FUSES CKSFSM                   //Clock Switching is enabled, fail Safe clock monitor is enabled
Ttelmah



Joined: 11 Mar 2010
Posts: 19195

View user's profile Send private message

PostPosted: Thu May 02, 2019 1:11 am     Reply with quote

The issue seems to be specific to your chip.
Using a 24HJ256GP610, it compiles fine. On the 24EP512GU814 it gives
your problem.
Now I can understand there being a problem, since your chip has more than
32K of data space. How to handle allocating a RAM window into the program
memory, when more than 32K of RAM exists, is always going to be an issue.
Would require implementing RAM address pointers, that are larger than
64K, and bank switching every time an address above this boundary is
required. Given that PSV is being specified to use a 16bit address (this is
what the '16' is in the PSV setup), and there has never been any suggestion
from CCS that they do offer an option to use a larger address (PSV=32),
It is difficult to see how PSV can be used on chips that have for than 32K
of RAM....
SergioMForster



Joined: 23 Jan 2019
Posts: 29
Location: Argentina

View user's profile Send private message

PostPosted: Fri May 03, 2019 8:22 am     Reply with quote

Actually I do not see any reason for RAM error when adding the #device PSV=16 with the files can-pic24.c and can-pic24.h since in these files there is no reference to the ROM (like #ROM or #const).

Actually CCS uses a 15-bit pointer (32KB) to point to the RAM SPACE address image of the tables in ROM.

The compiler always gets the low 15 bits right. The next 8 bits are specified in the low byte of DSRPAG register.

Manually modifying the DSRPAG is a workaround for when the tables in rom exceed 32 KB.

But unfortunately there are other unwanted collateral effects when using PSV in CCS.


When the switch "#device PSV = 16" is enabled, the function read_rom_memory (address, dataptr, count) stops working correctly. (I suppose something similar happens with the function write_program_memory (address, dataptr, count), although I could not test it).

I suppose it is due to the problem that the symbols are not pointing to the actual address in ROM, as they are pointing to the PSV visibility area.

This problem I have already raised to CCS Support in February, they promised a new function, but until now I have not seen it implemented.

"We will add a function in the next release called REAL_ADDRESS() that will return the true ROM address of a variable."

I also found other problems with CCS libraries, derived from the use of PSV = 16.

I have not yet tested it, but there may be other potential problems related to not having the real address in ROM in C.

For example in the library math.h there are several arrays that are saved in ROM. Could this problem affect the mathematical functions, when the switch "#device PSV = 16" is enabled?
Code:

// Overloaded function exp() for data type - Float64
float64 const pe_64[12] ={9.30741400474913e-011,-4.28655416283316e-011,
                          8.71486547014137e-009,9.84458531538385e-008,
                          1.32588296983536e-006,1.52489283823016e-005,
                          0.000154037598423921,0.00133335487036216,
                          0.00961812936407326,0.0555041086222122,
                          0.240226506962827,0.693147180559823};

float32 const pl[4] = {-1.080310025160955, 1.999999947089217};
float32 const ql[4] = {0.091284365719509, -0.873491916557671};

// Overloaded function log() for data type - float64
float64 const pl_64[4] = {-0.145694052150681, 1.365485300000370,
                          -3.120535668274329, 2.000000000000000};

float64 const ql_64[4] = {0.006047500465908, -0.208298281937234,
                          1.113943039156721, -1.893601167470470};

float32 const pas[3] = {0.49559947, -4.6145309, 5.6036290};
float32 const qas[3] = {1.0000000,  -5.5484666, 5.6036290};

As a personal conclusion, PSV is a very powerful tool, but I think it is not mature in the current implementation of CCS, so it brings more problems than solutions.

Also the CCS support when PSV is mentioned is very bad, 5 days ago I raised this case to CCS and until now no one answered me.

my recommendation is not to use PSV
Ttelmah



Joined: 11 Mar 2010
Posts: 19195

View user's profile Send private message

PostPosted: Fri May 03, 2019 10:41 am     Reply with quote

Ther point is that on your chip there is more than 32K of RAM, so the
compiler will be using the whole 16bit address range for RAM. If you
enable PSV, depending on how CCS organises the RAM usage, it can
start putting variables into the area reserved for PSV. Result conflict....
SergioMForster



Joined: 23 Jan 2019
Posts: 29
Location: Argentina

View user's profile Send private message

PostPosted: Thu May 09, 2019 3:18 pm     Reply with quote

The answer of CCS Support: On this chip it is not possible to use the CN module in PSV=16 mode. The CAN bus modules uses that RAM. Shocked Confused

my recommendation is not to use PSV Evil or Very Mad Evil or Very Mad
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group