- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The generic family data sheet (e.g. PSoC® 5LP: CY8C52LP Family) indicates
"5.1 Static RAM ...... Code can be executed at full speed from the portion of SRAM that is located in the code space. This process is slower from SRAM above 0x20000000. ......."
There does not appear to be specific data sheets for individual devices so it's not clear where the internal SRAM is mapped within the memory space for devices with different size SRAM. I am using a device with 32K SRAM and PSOC creator linker places the RAM so that there is 16K below and above the 0x20000000 boundary, i.e. in two different 32K memory blocks. It places the stack at the top of this region, at 0x20004000.
My question is: are data accesses also slower to memory above 0x20000000?
If so can I move my stack below this address? .... there is a control for the stack size but I didn't find one for re-locating the stack in the SRAM.
- Labels:
-
PSoC 5LP
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Section 9.3 of the PSoC 5LP TRM and the bus interface section of the Cortex M3 TRM seem to be describe the issues in reasonable detail.
My interpretation is that the SRAM is organized as two banks capable of parallel access within a single cycle. That is a direct path from the CPU's Icode/Idata to the lower bank, as well as a data access through the System bus to the upper bank.
The upper bank is therefore faster for data accesses such as the stack. In fact it implies contention between *any* parallel accesses below 0x20000000, such as between instruction fetches from the FLASH cache and data access to the lower SRAM bank.
Disclaimer: I may easily have gotten this all wrong, though my optimization experiments so far seem to bear it out.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
This theread may help:
http://www.cypress.com/blog/psoc-insiders-blog/running-code-ram-using-psoc5-and-gcc-compiler