topic Re: MCF52259 and CW 7.1.1 pro (eval) returning value problem in ColdFire/68K Microcontrollers and Processors

MCF52259 and CW 7.1.1 pro (eval) returning value problem

francois_boucha — Wed, 01 Jul 2009 04:46:55 GMT

Hello,

There is a function that is supposed to return a pointer to a structure in the RAM, let's say it should return 0x200063FC. The problem I got with this function is that its always returning 0x1 and it causes the rest of my program to crash.

I know the function code itself is not the cause. I've used it already with no problem. (its pbuf_alloc() from lwip 1.3.0)

Maybe the target (internal FLASH) isnt set properly or some init code hasnt been called.

Thanks

Re: MCF52259 and CW 7.1.1 pro (eval) returning value problem

PaoloRenzo — Wed, 01 Jul 2009 12:34:47 GMT

Are you using some kind of RTOS with lwIP? CHeck if stack space is enough for task calling pbuf_alloc. Weird things happen when stack overflow selected space. Do not forget interrupts used with your project must be considered on each task's stack as well if RTOS is not using user/supervisor space to have a dedicated interrupt stack.

Also try to debug function

Hope this helps

Regards

Re: MCF52259 and CW 7.1.1 pro (eval) returning value problem

mjbcswitzerland — Wed, 01 Jul 2009 18:45:37 GMT

Are the two routines compiled with the same settings (eg. is one being taken from a library compiled differently?)

Note that there is a #pragma pointers_in_A0 (in mwerks.h) which defines how the project code is compiled. With this pragma set, routines which return addresses do so via the register a0 and data values are returned via d0. Without the pragma set both address and data values are returned via d0.

If you have, for example, this set when compiling a project but the library used was compiled without it you will find that the library returns an address in d0 but you application code will take the return value from a0 - which will be essentially undefined (but possibly always the same). A mismatch the otherway around will also cause returned addresses to be incorrect. Returned data values will however always match.

Just an idea...

Regards

Mark

www.uTasker.com
- OS, TCP/IP stack, USB, device drivers and simulator for M521X, M521XX, M5221X, M5222X, M5223X, M5225X. One package does them all - "Embedding it better..."

Re: MCF52259 and CW 7.1.1 pro (eval) returning value problem

francois_boucha — Wed, 01 Jul 2009 23:11:46 GMT

Hi Mark,

Interesting, and now how could I set this pragma globally?

Re: MCF52259 and CW 7.1.1 pro (eval) returning value problem

francois_boucha — Wed, 01 Jul 2009 23:12:31 GMT

No I'm in standalone lwIP...

thx for your help

Re: MCF52259 and CW 7.1.1 pro (eval) returning value problem

francois_boucha — Thu, 29 Oct 2020 09:50:33 GMT

I've just checked the register A0, and the return addresses seems to transit via register A0. I saw the return address in that register, and it is the same as the one I see in the debbuger. But p still affected with 0x1 after the call:

p = pbuf_alloc( PBUF_RAW, pNBuf->length, PBUF_POOL);

Re: MCF52259 and CW 7.1.1 pro (eval) returning value problem

francois_boucha — Thu, 29 Oct 2020 09:50:35 GMT

its funny, I've made a private function to test address returning value.

struct pbuf * ret_ptr(int a, int b, int c){ struct pbuf * q; struct pbuf poutine; poutine.len = 500; poutine.tot_len = 500; poutine.next = 0; poutine.type = 1; poutine.ref = 0;  ++c;  q = &poutine; return q;}

It work normally well when it is defined locally and called within the same module. But if it is declared in another module it always returns 0x1.

Could it be a heap problem?

Re: MCF52259 and CW 7.1.1 pro (eval) returning value problem

eGuy — Thu, 02 Jul 2009 00:44:30 GMT

Here in your example you have a common C language misunderstanding.

You can not return a pointer which points to a local variable!

'poutine' is out of scope when you return from the routine. so 'q' is points an in-valid location.

If you allocate 'poutine' as global variable, it should work.

When it is defined locally, you can treat that the variable is allocated in stack. when returns, the stack is cleard, p is points to invalid location ( that memory or stack reallocated by others.... ).

if you use p= new() or p= alloc() to allocate memory (from the heap ) in the module, unless you use delete() or free() to release the memory, the memory is always valid...

hope this helps.

Message Edited by eGuy on 2009-07-01 02:02 PM