Helpful ReplyXC16 v1.11 <symbol> may require an extended pointer for this device

Post
aspillman
Starting Member
2013/01/09 03:05:19
I'm using the dsPIC33EP512MU814 and have recently upgraded to the XC16 v1.11 compiler. I've read the release notes for the compiler www.microchip.com/mplabxc16readme and the Migration Issues with this new warning. However the I can't work out how to use the __eds__ qualifier to ensure the extended address is pointed to and make the compile warning go away.
 
For example I pass the address of a variable to a function:
 
 
/* variables declared inside function */
unsigned long int dw;
unsigned char ca[10];
unsigned char *ptr;
 
memcpy(&dw, ptr, 4);

This give me the warning: Taking the address of 'dw' may require an extended pointer for this device
 
 
If I try qualify the variable 'dw' with the __eds__ qualifier:
 
__eds__ unsigned long int dw;
unsigned char ca[10];
unsigned char *ptr;
 
memcpy(&dw, ptr, 4);

I get the errors: 
error: '__eds__' specified for auto variable 'w'
error: passing argument 1 of 'memcpy' from pointer to non-enclosed address space
 
If I make the variable 'dw' a global by declaring it outside of the function then it compiles without the extended pointer warning. This is not a very elegant solution and it does not working for passing the address of a pointer.
 
Is there a way to cast the address of 'dw', something like:
memcpy((__eds__)&dw,ptr,4);

post edited by aspillman - 2013/01/09 03:06:44
nice
Super Member
☄ Helpful
Re:XC16 v1.11 <symbol> may require an extended pointer for this device 2013/01/09 13:52:12
Is there a way to cast the address of 'dw'...

Yes:
memcpy ((__eds__ unsigned long *)&dw, ptr, 4);
Unfortunately memcpy doesn't support pointers to EDS space and hence the cast results in an error message you have already seen:
passing argument 1 of 'memcpy' from pointer to non-enclosed address space

As a workaround, you may allocate the stack below address 0x8000 and use your code as it is.
; File: stack.S        
#define STACK_SIZE  4096   // desired stack size in bytes (including the stack guardband)

.section non_eds_stack, stack, address(0x8000 - STACK_SIZE) ; allocate the stack below 0x8000
.space STACK_SIZE
Doing so doesn't eliminate the warning, but it can be safely ignored.

Does anyone know how to disable this warning? Adding -Wno-unknown_option to the command line should do the trick, but I can't find any documentation for this new warning, neither in the User's Guide nor by executing "xc16-gcc --help=warnings". 
 
Edit:
If I make the variable 'dw' a global by declaring it outside of the function then it compiles without the extended pointer warning. This is not a very elegant solution and it does not working for passing the address of a pointer.
Another workaround: Instead of defining 'dw' outside of the function, define it as static inside the function body. In that case 'dw' will only be visible inside the function, but isn't located on the stack.

Regards,
Bernd

post edited by nice - 2013/01/09 14:14:41
Blue_Key
Starting Member
Re:XC16 v1.11 <symbol> may require an extended pointer for this device 2013/07/10 20:31:55
I'm facing the same issue, the problem is that I'm using the stack of microchip for MDD and USB, both have this issue and generates hundreds of warning.
 
I've tried to fix them one by one but failed as it goes to too many locations. Seems the problem still on the last version of the stack.
 
Would this means that the Stack provided by microchip aren't even compatible with their compiler and devices ? 
 
My program is too big for the memory trick.
post edited by Blue_Key - 2013/07/10 20:42:38
xjag
Senior Member
Re:XC16 v1.11 <symbol> may require an extended pointer for this device 2013/07/12 01:50:46
Blue_Key

I'm facing the same issue, the problem is that I'm using the stack of microchip for MDD and USB, both have this issue and generates hundreds of warning.

I've tried to fix them one by one but failed as it goes to too many locations. Seems the problem still on the last version of the stack.

Would this means that the Stack provided by microchip aren't even compatible with their compiler and devices ? 

My program is too big for the memory trick.

I event don't understand why the compiler isn't able to use the "eds" by itself, especially when the large memory model was chosen.
I have the same problem here, by porting software libraries, previously written and compiled with the Microchip C18 compiler.
 
Blue_Key
Starting Member
Re:XC16 v1.11 <symbol> may require an extended pointer for this device 2013/07/15 01:43:31
That's really disappointing, especially when this is not specified anywhere.
 
If I knew all the trouble we would run on, I would probably have gone for devices from competitors.
 
Stack Microchip not compatible with E devices.
Different microchip stacks conflict each other.
ZigBEE PRO, not compatible with Microchip Zigbee sniffer, only compatible with a sniffer that doesn't exist anymore.
Expect to meet a LOT of problem with debugging, whether MPLAB8 or X, pickit or real ice.
IDE regularly crashing.
 
 
Blue_Key
Starting Member
Re:XC16 v1.11 <symbol> may require an extended pointer for this device 2013/09/22 19:35:41
What is the maximum size we can allocate with that method ?
 
I'm using FreeRTOS which allocates a heap of about ox2000 byte.
 
I'm not able to allocate more than into the
.section non_eds_stack, stack, address(0x8000 - STACK_SIZE) 8192 bytes without getting insufficient memory at linkage.
 
Datasheet specifies the allocation starts at 0x1000 so we have about 28k memory.
I don't have good knowledge into stack and memory allocation, is that due to the static allocation of variables ? Even so I still should have enough memory.[font="verdana, arial, helvetica, sans-serif; font-size: 10px; line-height: 2"] 
 
Blue_Key
Starting Member
Re:XC16 v1.11 <symbol> may require an extended pointer for this device 2013/10/10 02:40:32
Little update
 
For people like me who doesn't have enough memory left with the 0x8000 limitation trick, it seems the compiler still accept to have variable forced outside the stack.
 
__eds__ unsigned int MyBuffer[2000] __attribute__((address(0x8010), eds));