0

I have seen How to find the address of a variable when using AVR? - and the conclusion there is basically:

printf()-debugging on embedded targets is a bit complicated, you need to dig through and figure out if there's code to connect printf() with a serial port, and so on. Also, a full printf() can be a bit heavy, so perhaps you're already using a trimmed-down standard library. It's not the compiler's responsibility, you need to figure out how it's implemented.

... but I cannot really figure out why this problem of mine occurs.

I have a variable which I'd like to serve as an "array of strings", and which I'd like to malloc and realloc:

char** my_array = malloc(sizeof(char*)*1);

Then, I have printf redirected to "print" to USB serial port, and then I read the printouts in serial terminal.

As far as I know, the %p format specifier for printf should print an adress of a variable as a hexadecimal number. And I have a statement like this:

printf("my_array %p\r\n", (void *)&my_array);

I've also tried:

printf("my_array %p\r\n", &my_array);
printf("my_array %p\r\n", my_array);

In all cases, the printout I get is like this:

my_array  ▒▒▒ꓣ▒▒▒▒/▒▒f'w'▒`$▒▒W*▒▒X▒f'w'▒`$▒▒Y*▒▒Z▒f'w'▒`▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒#▒▒ ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒j▒{▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒i▒z▒▒`$▒▒

... which is, clearly, not a hexadecimal number.

Why does this happen, and what am I doing wrong? And how can I get an address of a variable printed as a hexadecimal number in AVR? If it matters, I use CodeVisionAVR compiler...

EDIT: found this:

https://www.avrfreaks.net/forum/format-specifier-pointers-0

But do people actually use %p and especially on an AVR. On an AVR a pointer is a 16bit unsigned number. I'd generally just use %04X or something myself.

(OK just realised this forum might mean 32bit ARM or UC3 where I guess the pointers are 32 bit? Even so %08X in that case)

... so I just used instead:

printf("my_array %08X\r\n", (void *)&my_array);

... and now I get as printout:

my_array 00003FFB

... but now I have no idea whether this is an actual address :)

sdbbs
  • 4,270
  • 5
  • 32
  • 87

1 Answers1

2

You can cast the pointer to a uintptr_t and print that:

printf("my_array %llu\r\n", (unsigned long long)(uintptr_t)&my_array);
dbush
  • 205,898
  • 23
  • 218
  • 273
  • 1
    Many thanks for that, @dbush - just a few notes: I use a 8/16-bit microcontroller, and for `%llu`/`unsigned long long`, I kept getting "Error: for 64-bit integer support please use 'math64.h'", even if I added `#include `. Going down to `%lu`/`unsigned long` got rid of that problem. `uintptr_t` needs `#include `. Finally, `%lu` prints a decimal number, for hex (https://stackoverflow.com/questions/29509452/) I ended up using `0x%08lX`. Now, I get `0x00000014` instead of `0x00003FFB`, not sure yet if it describes an actual address - but at least printf problem is solved. – sdbbs Feb 15 '19 at 16:39
  • 1
    @sdbbs _not sure yet if it describes an actual address_ — you are right, the value `0x14` can't be an _memory_ address in AVR because it located below IO port tom address (even more — in core register address range `0x00`-`0x1F`). – ReAl Feb 16 '19 at 08:58
  • Just one more note: I have tried something similar with a regular (not double, as in OP) `char* mytest`; I ended up checking it via `mytest == NULL`, and got via that printout, that it is indeed null; and for that particular case, it turns out I should write `printf( "0x%08lX\r\n" , (unsigned long)(uintptr_t)mytest);` - *without* the "adrress of" ampersand; this is what prints actual 0x0 as the address ( if I add the ampersand ( as in `(unsigned long)(uintptr_t)&mytest` ), then I get this 0x14 non-address instead. ) – sdbbs Feb 18 '19 at 13:55
  • Finally found why `%p` was producing corrupt output - the CodeVision AVR manual for `printf` states: "*'p' - the function argument is a pointer to a null terminated char string located in FLASH;*" - so `%p` has a different meaning from what it has in "desktop" C, where it prints a pointer in hex (and that is why I was also getting letters printed in the OP example) – sdbbs Mar 04 '19 at 10:57
  • @sdbbs Please post that as an answer to this question – val - disappointed in SE Sep 03 '20 at 16:10