error: unknown type name '__root'

[Freedom_Neo]

I am using below codes. But this define not supportted

#define KeepInCompilation __root

 

#define KeepInCompilation __root
 
/* Private function prototypes -----------------------------------------------*/
int Init ();
KeepInCompilation int Write (uint32_t Address, uint32_t Size, uint8_t* buffer);
KeepInCompilation int SectorErase (uint32_t EraseStartAddress ,uint32_t EraseEndAddress);
KeepInCompilation uint64_t Verify (uint32_t MemoryAddr, uint32_t RAMBufferAddr, uint32_t Size, uint32_t missalignement);
KeepInCompilation HAL_StatusTypeDef HAL_InitTick(uint32_t TickPriority);
KeepInCompilation int MassErase (uint32_t Parallelism );

[TDK · Accepted solution]

> #define KeepInCompilation __root

Why is this here at all?

After some searching, appears to be a macro for the IAR compiler. STM32CubeIDE uses GCC.

https://github.com/search?q=KeepInCompilation&type=code

Appears to be code that was blindly copy/pasted without the necessary #if statements.

https://github.com/chcbaram/stm32_ext_flash/blob/9724a4d5e393c3e84b7b190fcebe4269b21f5d2e/stm32h750_ext_flash_W25Q128FV/src/ap/Loader_Src.h#L20

[Tesla DeLorean]

Yes would typically be in an include file,

Whoever wrote this code must have had specific assumptions about the tools they were using, people lifting the code need to be aware of the tools that were used, and there exceptions, and adapt the code to work with their own tools, or use the more flexible definitions where it identifies a sub-set of common tools, and provides the appropriate directive.

The reason you need to "Keep" the entry points is that they aren't called internally, but need exporting externally as the loader is pulled in a bit like a DLL, and has multiple entry points, and isn't using main(), or the C run-time initialization methods.

I tended to deal with this at the Linker Script level

https://community.st.com/s/question/0D53W00000SbsggSAB/generating-external-loader-stldr-for-specific-hardware

https://community.st.com/s/contentdocument/0693W000006HJN7QAO

[TDK]

How do you call them if they're not called internally and aren't at fixed memory addresses? I guess you could examine the map file, but that seems awkward at best.

[Tesla DeLorean]

The things load as ELF object file (ie LINUX type shared objects, Windows DLLs)

The entry point export as symbols, STM32 Cube Programmer is pushing these loaders into RAM and selectively executing routines, like a debugger, and also moving blocks of data into other parts of RAM for the routines to Write / Verify into the External Flash memories.

Basically using the standard tools you already have for building these, but skipping that step at the end where you frost them into a .BIN or .HEX that gets burned into ROM/FLASH at some specific address. The .ELF would accommodate fixup/relocations, and perhaps re-basing, if you used all the features, but this stuff is relatively mundane single image, fixed location, rather than a shared object with multiple instances loaded, and perhaps a data context for each thread, etc.

[TDK]

Thanks, appreciate the response. I’m surprised the __root is required if building a DLL, but I’m no expert in that arena.

[FLuba.1]

About "KeeInCompilation".

KeepInCompilation int Write (uint32_t Address, uint32_t Size, uint8_t* buffer);

 Do we have to use this instruction in STM32Cube since it make it use of gcc compiler? Otherwise said: can we leave "KeeInCompilation" out of the rest of the code?

[Pavel A.]

"KeeInCompilation" macro is a misnomer. The intent is to keep the thing in the final image (after linking - not compilation!)

How this is implemented depends on the toolchain. For the IAR compiler this should be defined as "__root" and it is somehow passed to the linker. The GNU compiler knows attributes "used" and "unused" but these do not propagate to the linker (or the linker ignores them, I don't know). So for GNU toolchain, we change the linker script and define KeeInCompilation as nothing (better rename it to something more appropriate).

[FLuba.1]

Pavel A. thank you for the quick respond. I'm not a specialist when it concerns linker files.
You wrote: "So for GNU toolchain, we change the linker script and define KeeInCompilation as nothing (better rename it to something more appropriate)."

Could you please provide me an example code as the one you have described? I use STM32Cube IDE 1.11.2. Everywhere where "KeepInCompilation"is stated in stm32CubeIDE i have deleted it, it gave me errors in my code. When i deleted it,my error dissapeard. But i don't know if deleting "KeepInCompilation" would be the cause of my external loader not working properly in STM32CubeProgrammer.  I try to make an external loader, but have some errors in STM32CubeProgrammer.

[Pavel A.]

@FLuba.1 Examples were pointed by Tesla earlier in this and other threads. Basically you (a) put the needed functions in a custom section and (b) define this section in the linker script, in appropriate place, with attribute KEEP. This tells the linker not to discard that code as unused, AND place the code in specific way. But problem in your loader can be caused by something else. What exactly it is? Post a new thread, please.