Motorola DSP memory troubles

Hello

In my code I have the following statement

    memcpy( dest, src, size );

dest and src are UWord16*.

When I run the program with the codewarrior debugger, everything goes fine.
When I run without debugger, the memcopy does not succeed.
(I've seen it because I have some leds to debug)

any experiences??

Regards 


Steven Cool

>In my code I have the following statement
>
>    memcpy( dest, src, size );
>
>dest and src are UWord16*.
>
>When I run the program with the codewarrior debugger, everything goes fine.
>When I run without debugger, the memcopy does not succeed.
>(I've seen it because I have some leds to debug)
>
>any experiences??

It's hard to tell what is really happening without seeing more code. How do you
know the memcpy failed? You say you use LEDs but how? I assume you put a call
to light the LED after the memcpy and the LED isn't lighting up.

You also don't mention which Motorola DSP you are using.

Look at the pointers that you pass. They may not be valid. They might be
pointing off to nowhere. In this case, you'd get a Bus Error. They might be odd
(assuming that this Motorola DSP doesn't like addressing words on an odd byte
boundary like the 68000). In this case, you'd get an Addressing error.

You might try using any interrupts for these types of errors (actually all
errors) to catch them.

Steven Cool wrote:
> 
> In my code I have the following statement
> 
>     memcpy( dest, src, size );
> 
> dest and src are UWord16*.

No, they are of type void*, but the conversions are automatic.

> 
> When I run the program with the codewarrior debugger, everything
> goes fine. When I run without debugger, the memcopy does not
> succeed. (I've seen it because I have some leds to debug)

Are you sure the memory areas don't overlap?  You may need memove.

-- 
 "I support the Red Sox and any team that beats the Yankees"
 "Any baby snookums can be a Yankee fan, it takes real moral
  fiber to be a Red Sox fan"
 "I listened to Toronto come back from 3:0 in '42, I plan to 
  watch Boston come back from 3:0 in 04"

In article <41765067.29F4FF74@yahoo.com>, cbfalconer@yahoo.com says...
> Steven Cool wrote:
> > 
> > In my code I have the following statement
> > 
> >     memcpy( dest, src, size );
> > 
> > dest and src are UWord16*.
> 
> No, they are of type void*, but the conversions are automatic.
> 
> > 
> > When I run the program with the codewarrior debugger, everything
> > goes fine. When I run without debugger, the memcopy does not
> > succeed. (I've seen it because I have some leds to debug)
> 
> Are you sure the memory areas don't overlap?  You may need memove.
> 
> 

About  your sig:

 "I support the Red Sox and any team that beats the Yankees"
 "Any baby snookums can be a Yankee fan, it takes real moral
  fiber to be a Red Sox fan"
 "I listened to Toronto come back from 3:0 in '42, I plan to 
  watch Boston come back from 3:0 in 04"


I'm rooting for the Red Sox also.  But I'd REALLY like to
see the schematic of the device that allowed anyone to listen to to the
Toronto Blue Jays in 1942.  Or perhaps you quoting someone  mixing up 
hockey and  baseball  ;-)  


Mark Borgerson

 

Steven Cool wrote:
> Hello
> 
> In my code I have the following statement
> 
>     memcpy( dest, src, size );
> 
> dest and src are UWord16*.
> 
> When I run the program with the codewarrior debugger, everything goes fine.
> When I run without debugger, the memcopy does not succeed.
> (I've seen it because I have some leds to debug)

How are you calculating size? Any chance that size is being calc'd as 
bytes and is expecting words?

Bob

Mark Borgerson wrote:
> 
... snip ...
> 
> About  your sig:
> 
>  "I support the Red Sox and any team that beats the Yankees"
>  "Any baby snookums can be a Yankee fan, it takes real moral
>   fiber to be a Red Sox fan"
>  "I listened to Toronto come back from 3:0 in '42, I plan to
>   watch Boston come back from 3:0 in 04"
> 
> I'm rooting for the Red Sox also.  But I'd REALLY like to see the
> schematic of the device that allowed anyone to listen to to the
> Toronto Blue Jays in 1942.  Or perhaps you quoting someone mixing
> up hockey and  baseball  ;-)

That was the Toronto Maple Leafs beating the Montreal Canadiens in
seven games.  Definitely hockey, back when there were 6 teams. 
Meanwhile the Dodgers were in their proper home, along with the
Giants, Senators, Browns, etc.

Somebody (I think Sinclair) said "Toronto is the greatest unifying
influence in Canada, everybody hates it".  Similarly the Yankees in
the US.  Toronto has softened with time.

--

garykato@aol.com (Gary Kato) wrote in message news:<20041020064648.24078.00002452@mb-m13.aol.com>...
> >In my code I have the following statement
> >
> >    memcpy( dest, src, size );
> >
> >dest and src are UWord16*.
> >
> >When I run the program with the codewarrior debugger, everything goes fine.
> >When I run without debugger, the memcopy does not succeed.
> >(I've seen it because I have some leds to debug)
> >
> >any experiences??


Thank you for your reply


> 
> It's hard to tell what is really happening without seeing more code. How do you
> know the memcpy failed? You say you use LEDs but how? I assume you put a call
> to light the LED after the memcpy and the LED isn't lighting up.

This is the way I can see this:

****************************CODE***********************************************
memcpy( receivePDOParameter[offset].pindex[bSubindex].pObject, pbData,
dwSize );

if( *(receivePDOParameter[offset].pSubindex[bSubindex].pObject) ==
0xFF)
{
    ArchIO.PortC.dr |= 0x400;
}

****************************CODE***********************************************
I'm sure the value I write is 0xFF, So I have to come in the IF
statement.
bit 10 of the dr register is connected with a LED. The LED burns in
debug mode.
When I do the memcopy the UWord16* are casted to a void*. Maybe this
is the problem because a void pointer acts as a UWord8 pointer (and
devides the address with two). But why does it work in debug mode???

Maybe the problem is the allocation of the receivePDOParamter. But if
this is the problem, it shouldn't work in debug mode.


> 
> You also don't mention which Motorola DSP you are using.
> 

I'm using 56F8345 16-bit Hybrid Controller

> Look at the pointers that you pass. They may not be valid. They might be
> pointing off to nowhere. In this case, you'd get a Bus Error. They might be odd
> (assuming that this Motorola DSP doesn't like addressing words on an odd byte
> boundary like the 68000). In this case, you'd get an Addressing error.
> 
> You might try using any interrupts for these types of errors (actually all
> errors) to catch them.

CBFalconer <cbfalconer@yahoo.com> wrote in message news:<41765067.29F4FF74@yahoo.com>...

Thank you for your reply

> Steven Cool wrote:
> > 
> > In my code I have the following statement
> > 
> >     memcpy( dest, src, size );
> > 
> > dest and src are UWord16*.
> 
> No, they are of type void*, but the conversions are automatic.

When I pass them they are UWord16*. The conversion is automatic
indeed. But maybe this is the problem. Becaus a void* acts like a
char*.

> 
> > 
> > When I run the program with the codewarrior debugger, everything
> > goes fine. When I run without debugger, the memcopy does not
> > succeed. (I've seen it because I have some leds to debug)
> 
> Are you sure the memory areas don't overlap?  You may need memove.

I'm not sure. but if this is the problem, why dos it work in debug
mode

regars Steven

MetalHead <WanderingMetalHead@HATESPAM.yahoo.com> wrote in message news:<cPEdd.8$OL5.2072@news-west.eli.net>...
> Steven Cool wrote:
> > Hello
> > 
> > In my code I have the following statement
> > 
> >     memcpy( dest, src, size );
> > 
> > dest and src are UWord16*.
> > 
> > When I run the program with the codewarrior debugger, everything goes fine.
> > When I run without debugger, the memcopy does not succeed.
> > (I've seen it because I have some leds to debug)
> 
> How are you calculating size? Any chance that size is being calc'd as 
> bytes and is expecting words?
> 
> Bob

Bob,

Thank you for your reply

I think the size of the memcopy must be in bytes. But if this is the
problem should debug-mode still work?

regards 

Steven

>Maybe the problem is the allocation of the receivePDOParamter. But if
>this is the problem, it shouldn't work in debug mode.
>

It depends on exactly how debug mode is different from non-debug mode. You
might have to read up on the compiler to see which switches are used in which
mode and what those switches mean.

Whenever something works in debug mode and not in production mode, usually it's
a bad pointer or an uninitialized variable somewhere. Sometimes debug monitors
do things that aren't done in normal mode like zeroing out RAM or installing a
default interrupt handler for all interrupts. It also might have something to
do with where your program loads in memory. It might load in a different place
in debug mode and that might be the cause of your problem. You might want to
look at a cross-reference or map file that shows where all your code and data
get loaded. Generate such a file for debug and non-debug mode and see if
anything changes between the two.