This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

  • Resolved

Compiler/TMS320C6727B: Memmove / Memcpy Suspected Issues with interruptions

Part Number: TMS320C6727B

Tool/software: TI C/C++ Compiler

Hi,

I am trying to debug a problem where the DSP stops attending interruptions (EMIF).

I have tracked until memcpy: is it possible that it disables interruptions for better performance and, under some conditions, they are not re-enabled?

Is it possible that memmove has the same behaviour?

=========================================

Jose Luis Gomez Costa

CERN

  • Are you fiddling with the same block of memory the DMA is fiddling with?
  • In reply to Keith Barkley:

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

    =========================================

    Jose Luis Gomez Costa

    CERN

  • In reply to Jose Luis Gomez Costa:

    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.)
  • In reply to Jose Luis Gomez Costa:

    Could your memcopy() call be clobbering the stack? That could kill interrupts.

  • In reply to Keith Barkley:

    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

    CERN

  • Jose Luis Gomez Costa
    I have tracked until memcpy: is it possible that it disables interruptions for better performance

    Yes

    Jose Luis Gomez Costa
    and, under some conditions, they are not re-enabled?

    No.  Interrupts are always re-enabled.

    Thanks and regards,

    -George


    TI C/C++ Compiler Forum Moderator
    Please click This Resolved My Issue on the best reply to your question
    The CCS Youtube Channel
     has short how-to videos
    The 
    Compiler Wiki answers most common questions
    Track an issue with SDOWP. Enter your bug id in the Search box.

  • In reply to Jose Luis Gomez Costa:

    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().
  • In reply to Keith Barkley:

    Hi,

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

    =========================================

    Jose Luis Gomez Costa

    CERN

  • In reply to Keith Barkley:

    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.

    =========================================

    Jose Luis Gomez Costa

    CERN

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.