Electronics > Microcontrollers
This code is so broken it some how fixes itself.
paulca:
It's an H7, but I get the idea :)
paulca:
While I have you :) (sorry).
Is there a quick win to gain access to the DTCM SRAM? Googling finds me long linker script modifications.
Can't I just ignorantly use hard coded offsets by casting an integer like 0x200000 to a pointer? I'm only declaring 4 tiny arrays.
thm_w:
Guess its harder than ITCM for some reason?
--- Quote ---@note Some code parts can be executed in the ITCM-RAM (64 KB) which decrease critical task execution time, compared to code execution from Flash memory. This feature can be activated using '#pragma location = ".itcmram"' to be placed above function declaration, or using the toolchain GUI (file options) to execute a whole source file in the ITCM-RAM.
@note The application needs to ensure that the SysTick time base is always set to
1 millisecond to have correct operation.
@Note For the Cortex-M7, if the application is using the DTCM/ITCM memories (@0x20000000/ 0x0000000: not cacheable and only accessible
by the Cortex-M7 and the MDMA), no need for cache maintenance when the Cortex M7 and the MDMA access these RAMs.
If the application needs to use DMA(or other masters) based access or requires more RAM, then the user has to:
- Use a non TCM SRAM. (example : D1 AXI-SRAM @ 0x24000000)
- Add a cache maintenance mechanism to ensure the cache coherence between CPU and other masters(DMAs,DMA2D,LTDC,MDMA).
- The addresses and the size of cacheable buffers (shared between CPU and other masters)
must be properly defined to be aligned to L1-CACHE line size (32 bytes).
--- End quote ---
https://github.com/STMicroelectronics/STM32CubeH7/blob/master/Projects/STM32H747I-EVAL/Templates_LL/readme.txt
https://community.st.com/s/question/0D53W00001sKgU0SAK/stm32cubeide-doesn-not-support-declaring-variable-in-dtcm-on-stm32h7-directly
Nominal Animal:
--- Quote from: paulca on February 01, 2023, 09:24:12 pm ---It's an H7, but I get the idea :)
--- End quote ---
H7 is Cortex-M7, so also ARMv7E-M, but with newer FP with double precision support (+fp.dp), so you'll want to use
gcc -O2 -march=armv7e-m+fp.dp -mtune=cortex-m7 -mthumb ...
or
clang -Os -target=arm-arm-none-eabi -mcpu=cortex-m7+fp -mthumb ...
to compile the code. I use these for i.MX RT1062 (Teensy 4.x), too: it has a very similar ARM Cortex-M7 core (but NXP, not ST).
The same documentation applies.
The cycle counts are likely completely off, though, since I can find them only for Cortex-M0 and Cortex-M4, not Cortex-M7.
--- Quote from: paulca on February 01, 2023, 09:26:22 pm ---Is there a quick win to gain access to the DTCM SRAM?
--- End quote ---
You can use a fixed pointer to access DTCM SRAM. Thing is, how will you ensure the addresses you use are not used by the compiler and/or linker already?
That is why modifying your linker script, typically by declaring a section that will be placed in the correct addresses, is used. If you ensure section "dtcm" is placed in the correct region, then
static type arrayname[count] __attribute__((section "dtcm"));
puts the array at the correct section, so it will end up in the correct memory addresses, and the linker will decide its exact address. Without modifications or support from the startup (startup.s, I believe), it will be uninitialized (have random contents) after bootup.
If you can show the linker script you already use (look for "Linker script for STM32H7 series", file name probably ends with .ld), and it does contain the "This software component is licensed by ST under BSD 3-Clause license", then you are allowed to publish it here and I can show how to modify it to add such a section. Most likely, it is just one added line.
paulca:
Looked back into this today.
It would seem the linker script is already setup to use the DTC RAM. However, most things get allocated in RAM_D1 'above' it.
Linker script attached. I believe it's BSD license.
Any quick wins?
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version