View previous topic :: View next topic |
Author |
Message |
skelzer
Joined: 21 Apr 2016 Posts: 20 Location: Spain
|
Writing outside dsPIC33EP512GP504 near ram |
Posted: Thu Apr 21, 2016 2:05 am |
|
|
Hello there,
I'm having some problems while trying to use more than 4Kbyte of RAM. Any time I exceed that limit the microcontroller will go completely haywire.
The thing is this dsPIC has 8Kbyte of near-data space (4k for SFR) so I guess when it reaches address 0x1FEE it just goes back to 0x0000 and starts overwriting all my SFR data.
Any idea on how to avoid this? Is there any way to tell the compiler which address I want for data in RAM?.
Memory structure is in page 55 of the datasheet : http://ww1.microchip.com/downloads/en/DeviceDoc/70000657H.pdf
Cheers. |
|
|
Ttelmah
Joined: 11 Mar 2010 Posts: 19520
|
|
Posted: Thu Apr 21, 2016 3:36 am |
|
|
Start with the obvious question. What compiler version?.
What are you actually trying to 'do' in the RAM?. Just variables, or something more complex?.
The compiler handles over the 4KB fine for me, on another chip in the same family. It does indexed addressing directly to things like arrays, which handles the address space as linear. It's only the direct addressing through instructions which can't handle the larger address spaces.
There were problems with larger address spaces on much older compilers |
|
|
skelzer
Joined: 21 Apr 2016 Posts: 20 Location: Spain
|
|
Posted: Fri Apr 22, 2016 12:58 am |
|
|
Ttelmah wrote: | Start with the obvious question. What compiler version?. |
5.045
Ttelmah wrote: |
What are you actually trying to 'do' in the RAM?. Just variables, or something more complex?. |
It's a 3-dimensional array of signed int16 data. (signed int16 array[3][5020])
I've tried to declare several arrays instead of a big one, but yielded the same results. |
|
|
Ttelmah
Joined: 11 Mar 2010 Posts: 19520
|
|
Posted: Fri Apr 22, 2016 2:33 am |
|
|
Talk to CCS.
What is happening is not related to the near data space limitations. You are hitting a problem with handling an array this large. A single 30KB array!..
It won't be accessing an array with short addressing. All array accesses are done using indexed addressing, which is not affected by the near memory space limitations.
If you look at the symbol file, you will find it has only actually allocated about 5KB for the array.
CCS internally use a 13bit counter for some array operations. It is the limitation of this, that you are hitting.
If (for instance), you allocate an int32 array with 2047 elements, this will work fine. However increase the size to 2048 elements, and it'll fail.
Interestingly though the next variable allocated, will be correctly placed as if the array was 2048 elements long.... |
|
|
skelzer
Joined: 21 Apr 2016 Posts: 20 Location: Spain
|
|
Posted: Tue Apr 26, 2016 5:52 am |
|
|
I've successfully declared (and used) a bigger array now, just used the directive #locate and located the array in a bigger memory slot.
It's terribly counter-intuitive how this work, to be honest... Thank you very much Ttelmah for trying to help on this |
|
|
skelzer
Joined: 21 Apr 2016 Posts: 20 Location: Spain
|
|
Posted: Tue Apr 26, 2016 5:54 am |
|
|
How this works*
(Forum wouldn't let me edit my last post and my eyes were bleeding.) |
|
|
Ttelmah
Joined: 11 Mar 2010 Posts: 19520
|
|
Posted: Tue Apr 26, 2016 8:10 am |
|
|
The point is that you shouldn't have to be doing this, as I said, contact CCS.
The actual handling of the arrays is fine, but the generation of them fails if they are over 8KB. You can generate 4 8KB arrays fine, but not a single 32KB one.
Yes you can cheat an allocate the space yourself, but why bother?. It is something that I'd expect them to be able to quickly fix, especially given it is not in the fundamental 'use' of the array, but just in it's locating. |
|
|
skelzer
Joined: 21 Apr 2016 Posts: 20 Location: Spain
|
|
Posted: Tue Apr 26, 2016 8:46 am |
|
|
Ttelmah wrote: | The point is that you shouldn't have to be doing this, as I said, contact CCS.
|
Will do! |
|
|
|