Hi Willian,
At first, I would like to mention that SRAM_U has a size of 60 KB. That is why you have had difficulties with placing two 32 KB arrays into the m_data_2 section.
You can refer to RM rev 12.1
There are two regions:
- SRAM_L from 1FFF_0000h to 1FFF_FFFFh
- SRAM_U from 2000_0000h to 2000_EFFFh
There is an important note:
"Misaligned accesses across the 2000_0000h boundary are not
supported in the Arm Cortex-M4F architecture"
So, that is why it is easier to have two RAM segments in the linker file.
Also, I suggest you to look at the linker file of the project to see what else is placed in the m_data/ m_data_2 sections (heap, stack).
Best regards,
Diana
Hi Ahmad,
At first, I would like to suggest looking at RM rev 12.1 section 33.2.1. Each region uses a different bus:
When you look at the linker file of some project, you can see that SRAM_L (m_data) includes the code_ram section, global variables, vector table. SRAM_U (m_data_2) contains stack and heap.
The benefit of this approach is described in the AN below in the section "3.1 SRAM accesses"
https://www.nxp.com/docs/en/application-note/AN4745.pdf
"The dual SRAM blocks allow the SRAM controller to handle simultaneous accesses to the SRAMs as long as
those accesses are not to the same SRAM block. Allowable simultaneous accesses to the SRAM are:
• Core CODE (SRAM_L) and core system (SRAM_U) accesses
• Core CODE (SRAM_L) and non-core master to SRAM_U
• Core system (SRAM_U) and non-core master to SRAM_L
Strategic placement of code and data into each of the SRAM blocks can help to increase parallelism and overall performance.
For a typical application, placing critical code in the SRAM_L block and placing data and the stack into the SRAM_U block
will yield the best performance."
Best regards,
Diana
