-1

I have a code-block, which is written in C for IAR C/C++ Compiler.

__no_init uint8_t u8ramPhysStart_startUp @ 0x20000000;
__no_init uint8_t u8ramPhysEnd_startUp @ 0x2002FFFF;
__no_init uint8_t u8ramTestStart_startUp @ 0x20004008;
__no_init uint8_t u8ramTestEnd_startUp @ 0x20008008;

#define START_ASM  (&u8ramPhysStart_startUp)
#define RAMSTART_STRTUP     ((uint32_t)START_ASM)

My goal is converting it or rather making it GCC compatible. For this, I rewrite above code like:

unsigned char u8ramPhysStart_startUp __asm("@ 0x20000000");
unsigned char u8ramPhysEnd_startUp __asm("@ 0x2002FFFF");
unsigned char u8ramTestStart_startUp __asm("@ 0x20004008");
unsigned char u8ramTestEnd_startUp __asm("@ 0x20008008");

But after compilation I get following error:

C:\Users\Pc\AppData\Local\Temp\ccyuCWQT.s: Assembler messages:
C:\Users\Pc\AppData\Local\Temp\ccyuCWQT.s:971: Error: expected symbol name
C:\Users\Pc\AppData\Local\Temp\ccyuCWQT.s:972: Error: expected symbol name

Do someone knows, what it means?

nasil122002
  • 127
  • 1
  • 3
  • 15
  • The syntax is incorrect, you cannot mix ASM and C in the same line like this. To force the address : you can use attribute section + linker script (NOLOAD to make the section initialized), or if you want GCC and IAR compatibility, have a look here: https://stackoverflow.com/questions/4067811/how-to-place-a-variable-at-a-given-absolute-address-in-memory-with-gcc – Julien Apr 16 '18 at 07:56
  • Thank you for the answer. Now with `int *u8ramPhysStart_startUp = (int*)0x20000000;` insteat of `unsigned char u8ramPhysStart_startUp __asm("@ 0x20000000");` it compiles. – nasil122002 Apr 16 '18 at 08:14
  • What does symbols do? Arethey just the addresses of the start and end of the section to be used in the startup code? – 0___________ Apr 16 '18 at 10:35

1 Answers1

2

I believe the gcc code should be something like

uint8_t __attribute__ ((section(".my_section"))) u8ramPhysStart_startUp;

where .my_section is something you have added to the linker script.

That being said, the only way which you can make allocation at absolute addresses portable, is to stick to pure ISO C:

#define u8ramPhysStart_startUp (*(volatile uint8_t*)0x20000000u)

or in case you want a pointer to an address:

#define u8ramPhysStart_startUp ((volatile uint8_t*)0x20000000u)

The disadvantage of this is that it doesn't actually allocate any memory, but relies on a linker script to handle that part. That's preferable in most cases.

Another disadvantage is that you won't be able to view these "variable" names in a debugger, since they are actually not variables at all. And that's the main reason why some tool chains come up with things like the non-standard @ syntax.

Lundin
  • 195,001
  • 40
  • 254
  • 396
  • I think that he just is looking for the addresses not the actual variables. BTW definitions are same visible in the debugger as "normal" variables. You just need to have high enough debug level. – 0___________ Apr 16 '18 at 10:41
  • @PeterJ_01 Depends on the debugger and the debugger file format. – Lundin Apr 16 '18 at 10:57
  • true - but seeing the addresses is quite easy to deduce what uC OP uses and both compilers mentioned are able to generate a proper debug data. Also popular debuggers are able to use this data as well – 0___________ Apr 16 '18 at 11:11