Motorola DSP memory troubles

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
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

Re: Motorola DSP memory troubles
Quoted text here. Click to load it

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.



Re: Motorola DSP memory troubles
snipped-for-privacy@aol.com (Gary Kato) wrote in message
Quoted text here. Click to load it


Thank you for your reply


Quoted text here. Click to load it

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.


Quoted text here. Click to load it

I'm using 56F8345 16-bit Hybrid Controller

Quoted text here. Click to load it

Re: Motorola DSP memory troubles
Quoted text here. Click to load it

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.



Re: Motorola DSP memory troubles
snipped-for-privacy@aol.com (Gary Kato) wrote in message
Quoted text here. Click to load it

Thank you for your reply.

I think I'm getting a little closer to my solution now.

I think I must have a variable that is not initiatlized.

I have a c-file which initializes all variables.
That's the only thing that the c-file does.

Mayb I should place everything in a function and call the funtion to
allocate all the global variables.

The searching goes on....

Re: Motorola DSP memory troubles

Quoted text here. Click to load it


That snippet is too abridged to be debuggable via Usenet, and internally
at least somewhat inconsistent.

*) is dwSize == sizeof (UWord16)?

*) For the test to be meaningful, you should be testing for the
manifestly *same* value you wrote into there.  Your implicitly claims
you know that pbData is 0xff with more certainty than you trust your
compiler/library maker to be able to implement memcpy().  Such claims
have a habit of coming back to haunt you...

--
Hans-Bernhard Broeker ( snipped-for-privacy@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.

Re: Motorola DSP memory troubles
Quoted text here. Click to load it


Hello, my problem is solved

The problem was that i did not copy the flash to ram when initializing.
All my initialized data got lost

thanks to all repliers of my messages

regards Steven

Re: Motorola DSP memory troubles
Quoted text here. Click to load it

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

Bob

Re: Motorola DSP memory troubles
Quoted text here. Click to load it

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

Re: Motorola DSP memory troubles

Thank you for your reply

Quoted text here. Click to load it

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*.

Quoted text here. Click to load it

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

regars Steven

Site Timeline