Hi Tim, I am not a linker script expert neither. But I'll let here a helpful link that helped me a lot:
https://interrupt.memfault.com/blog/how-to-write-linker-scripts-for-firmware Em ter., 8 de jun. de 2021 às 10:19, Sebastien Lorquet <sebast...@lorquet.fr> escreveu: > what I would check here (just a live tought process) > > * check that the ld file is actually used (ld file is pointed by main > Make.defs IIRC) (easy: just add garbage in it and verify build actually > breaks) > > * check that the driver source with the definition is being recompiled > > * check that the object file that contains the isram based definition > actually shows the use of the new section > > * make distclean, restart with a fresh build tree, rebuild all > > * reboot machine if possible (im not joking) > > Seems obvious, but sometimes bugs are hiding where we're assuming > they're not > > Sebastien > > Le 08/06/2021 à 15:12, Tim Hardisty a écrit : > > Thanks, but still no cigar :( > > > > I have tried: > > > > .isramdata_reserve (NOLOAD) : > > { > > *(.isramdata) > > . = ALIGN(4); > > _isramdata_heap_start = ABSOLUTE(.); > > } > isram > > > > and also just > > > > .isramdata(NOLOAD) : > > { > > *(.isramdata) > > } > isram > > > > along with trying > > > > staticuint32_tg_mcan0_msgram[MCAN0_MSGRAM_WORDS] > > aligned_data(MCAN_ALIGN) locate_data(".isramdata"); > > where MCAN_ALIGN is ARMV7A_DCACHE_LINESIZE, which is 32 > > or > > static uint32_t g_mcan0_msgram[MCAN0_MSGRAM_WORDS] __attribute__ > > ((section (".isramdata"))); > > and all methods still report this as in SDRAM not ISRAM > > On 08/06/2021 13:33, David Sidrane wrote: > >> Here is a working example. > >> > >> > >> > https://github.com/apache/incubator-nuttx/blob/master/arch/arm/src/stm32h7/stm32_spi.c#L715-L716 > >> > >> > >> > https://github.com/apache/incubator-nuttx/blob/master/boards/arm/stm32h7/nucleo-h743zi/scripts/flash.ld#L179-L184 > >> > >> > >> You can check it the arm-none-eabi-nm -C nuttx.elf | grep g_mcan0_msgram > >> > >> David > >> > >> -----Original Message----- > >> From: Tim Hardisty [mailto:t...@jti.uk.com] > >> Sent: Tuesday, June 08, 2021 4:23 AM > >> To: dev@nuttx.apache.org > >> Subject: Re: Memory locations > >> > >> > >> On 07/06/2021 19:06, Nathan Hartman wrote: > >>> On Mon, Jun 7, 2021 at 12:24 PM Tim wrote: > >>>> I will, I believe, need to declare - place - MCAN related > >>>> structures such > >>>> that they (or at least some elements of them) are in SRAM. > >>>> > >>> Yes. It is possible. It is done by adding attributes in the code which > >>> tell the compiler that an object should be located at a particular > >>> address or section. > >> I have added this to my linker script (and other variations on that > >> theme, all of which compile OK with no warnings or errors) > >> > >> .isramdata : > >> { > >> } > isram > >> > >> and declared > >> > >> static uint32_tg_mcan0_msgram[MCAN0_MSGRAM_WORDS] > >> __attribute__((section(".isramdata"))) = {0}; > >> But it does not place the array in isram :( > >> system.map states: 20053fc4 D g_mcan0_msgram > >> which is confirmed by the debugger and an info debug message > >> Is there anything overruling this? Or a silly mistake, given my > >> inexperience with linker scripts? > >> Any guidance much appreciated! > > >
