ARM Compiler generated problematic instruction

Hi Guosheng,

Guosheng said:

I have a simple function (memcpy16lite()) to copy 16-bit data from Shared RAM to SDRAM.

How do you say that the source address and the destination address is pointing to the shared RAM and SDRAM??.

Is the SDRAM is interfaced through EMIFA or DDR2/Mobile DDR Memory Controller ??

As per the data sheet of OMAPL138, in the memory map table ,

1. From the start address, 0xC0000000 to end address 0xDFFFFFFF, it will be mapped to DDR2

2. 0x4000 0000 0x5FFF FFFF 512M EMIFA SDRAM data (CS0)

3. 0xFFFF0000 - 0xFFFF 1FFF to 8K ARM local RAM and  ARM Local RAM (PRU0 only).

To narrow down the problem further, you can hard code a valid memory address of shared RAM and the SDRAM and check whether the memory copy works fine without any issues between RAM and SDRAM.

Regards,

Shankari 

Please read my questions carefully. I have indicated in the very first thread that I am using OMAPL137.

And....

The problem is not about which memory I access. The problem is about a bad assembly code being generated which try to load some unknown data in the memory as an address to write to.

Please pay attention to the assembly code generated. It does not correctly perform what the C code intend to perform.

And FYI, I am very sure address I used was in the correct memory range, be it SHARED RAM or SDRAM.

I am able to read and write to the memory region in the debug memroy window.

HI guosheng,

O!. yes, I should have referred to the Datasheet of OMAPL137.

But still that is a valid point.; ie., checking whether the pointing address is accessible and valid. In your post you have mentioned that an "odd" destination address is passed as a parameter to the function. You have to find out why that address is perceived as odd by you and who calls this function with those odd values in your app code.

Usually,  the assembly code generated cannot be incorrect. Usually memory related problems will give wierd results.

Instead of suspecting the converted assembly code, you may have to focus on the address you passed as a source and destination for memory copy. To debug further, split the memory copy 'C' code as multiple lines of operations instead of single line " *pbyDst++ = *pbySrc++  ". For example, as

...............................

*pbyDst = *pbySrc;

pbyDst++;

pbySrc++;

}

This will give atleast some clarity in your while loop iteration that at what point the memory address becomes invalid.

If you still think there is some problem in converting the C code into assembly code, please post your query on TI C/C++ compiler forum.

Regards,

Shankari

-------------------------------------------------------------------------------------------------------

Please click the Verify Answer button on this post if it answers your question.
--------------------------------------------------------------------------------------------------------