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

[SergioMForster]

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]

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.

[SergioMForster]

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]

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.
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]

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...

[SergioMForster]

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

[Ttelmah]

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]

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?

[Ttelmah]

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]

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.

my recommendation is not to use PSV