Compiler/TMS320C6727B: Memmove / Memcpy Suspected Issues with interruptions

Are you fiddling with the same block of memory the DMA is fiddling with?

Hi,
We are not using DMA in our tasks, do you mean that memcpy could use it?

Sorry, saw DSP and jumped to DMA in my head. You should be able to find the source for memcopy() and check it out for yourself.

The compiler's version of memcpy does not explicitly disable interrupts.
Just to double-check, what version of the compiler are you using? (It is not the same as the CCS version.)

Hi,
we have checked, and we are at 70% of the stack memory. I do not think this can be an issue

Jose Luis Gomez Costa said:

I have tracked until memcpy: is it possible that it disables interruptions for better performance

Yes

Jose Luis Gomez Costa said:

and, under some conditions, they are not re-enabled?

No.  Interrupts are always re-enabled.

Thanks and regards,

-George

I did *not* say you were running out of stack, I was saying you might be clobbering the stack. For example you may be telling memcopy() to copy twice as much memory as you want because of an errant sizeof().

Hi,

Sorry, I misunderstood the English word.
I will check, the data length to be copied is dynamic.

Hi,

Our system moves up to 8Kbytes of data from external memory (via EMIF). If we have small number of points to move, this problem does not appear.
We have modified our program to transfer always the same high amount of data, and we have noticed:
- The system works fine, we can notice that the full set is correctly transferred
- After random time (10 to 15 minutes, we made the data transfer every 1.2 sec), the interruptions stops being enabled after the memcpy, the only solution is to reset the system.
- We have modified our program, eliminated memcpy call, made the transfer "by program", and the system works fine.

The Interruption that keeps masked is connected to EMIF block

This thread has moved beyond the expertise of us compiler experts.  Is your problem resolved?

Thanks and regards,

-George