Using PSV with large rom arrays with PIC24EP512GU814

[SergioMForster]

I'm developing a project with the CCS PCD v5.082 compiler.

The project includes a pic24EP512GU814 that manages among other things a S1V30120 tts chip, a MPU6020 IMU, a graphical LCD display and other things.

The S1V30120 requires that at the very beginning after reset, PIC sends an initialization code to its ram of around a 32 kb array (that should have been stored in the ROM of the PIC).

The MPU6050 requires something similar but the initialization code is of around 3 Kb array.

I also have for the LCD several arrays for fonts and graphics.

I have read that the PIC24EP512GU814 "have a feature that allows part of their ROM to be mapped into the RAM address space. Program Space Visibility. On these chips enabling the feature by adding #device PSV=16, will allow RAM pointers to access const/rom data directly through this feature".

On the CCS manual it is not well documented the functionality and limitations of the PSV=16 feature.

I have tested that PSV works well with small arrays, but with large arrays the functions with pointers to ROM, points to missed places and the information that i read from the rom is erroneous.

Keeping in mind that the functions that use the big arrays, they only run at the very beginning of the program. How I can solve this problem for not having to make it in the old way with read_program_memory(), with a high cost of RAM ?

Thanks in advance for your suggestions.

[Ttelmah]

Talk to CCS.

I was having issues with PSV, and 5.081. They sent me a fix, and I must
admit I had assumed this was present in 5.082, though I have not had
cause to use it with this compiler yet. It sounds as if the problem is still
there though....

However I can see this being quite complex, since the total PSV window
is 'only' 32KB. Whether they can offer a way to support more than one
page at a time, is questionable, so it might be worth instead putting
all the data simply into ROM, and just reading the parts you need without
PSV.

To support PSV, giving an address beyond 64KB, would involve both page
switching the PSV window, and implementing a RAM address beyond
64KB to handle this, so would cost quite a lot in code terms, which
probably makes using the simpler ROM access likely to be simpler.

read_program_memory, does not need to have a 'large cost in RAM'. You
can load (say) 1KB), deal with this, and then load more.

[SergioMForster]

Thanks Ttelmah for your prompt answer.

I am following this topic with CCS Support, but as they requested me an example project where the problems were verified, I had to isolate a part of a bigger project so that they can test this issue.

I believe that there is a bug in the handling of PSV and arrays on program memory, since in the symbols file "project.SYM" are not well calculated the size of my array of 31208 bytes (0x79E8 in hex) and they calculate 0x1978 bytes in hex (6632 bytes).

In fact 32K are not a limit for PSV, by means of the CORCON and PSVPAG registers, several 32K PSV windows of 32k can be managed.

Here is a very useful link, where the use of PSV in microchip is very well explained http://microchipdeveloper.com/16bit:psv

When I get a solution from CCS, I will post the results here.

Another thing that I observed, and it is not documented on the ccs manual, it is that you cannot use the read_program_memory function, once the #device PSV=16 switch was enabled on the project

Thanks for your help.

[Ttelmah]

Yes,
but the key point I was making is that to handle beyond 32k, will require
more than 64k addresses be handled, and it was this that potentially imposes
a limit.

64k is a limit, since it is the 16bit limit. Now whether CCS handle this I do
not know.... However it does sound as if your total requirement is beyond
32K, and so potentially this is an issue.

Using the standard 'RAM' address, to talk to ROM inside the PSV, requires
that this address is large enough to access the area in the PSV window
as well as the RAM. Obviously OK with just one 32K window, but not
if you are using multiple windows. Will imply that all 'RAM' addresses
become 32bit values. Result slower/bulkier code....

[SergioMForster]

Do you have idea of as much as CCS support delays to respond on the problems?

It already lapsed one week since I sent the example project that CCS requested me with the erroneous behavior, and I don't still receive any answer.

The case status continues the same as the first day:

The current status is as follows:
As of yet, we have not had time to further review your e-mail

Do you know if exists some way to activate the answer?

Thanks in advance.

[dluu13]

I usually have had reasonably prompt responses from CCS. Maybe try and email them again with the same case number.

[Ttelmah]

If it is taking a time, it implies the solution/problem is not obvious to them
so they are having to investigate for longer.