Motorola DSP memory troubles

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.

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

Bob

Thank you for your reply

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.

I'm using 56F8345 16-bit Hybrid Controller

Thank you for your reply

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

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

regars Steven

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

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.

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

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 (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.

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