• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 98 subscribers
  • Views 992 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

DSPLIB question on DSPF_sp_blk_move function

Cryptoman
Intellectual 870 points

 

Hi,

I would like to use the block move library function as part of my design on 6713. While reading spru657c.pdf, I came across the following line in section "B-3 : Known issues" of the document:

"The DSPF_sp_blk_move function corrupts the next two returning lines of code."

This statement got me confused as it seems to suggest that one can use the DSPF_sp_blk_move() function at their own risk and potentially upon returning from this function, the program counter may branch off to some unexpected part of the code due to the two-line corruption mentioned.

At first I thought of using a couple of dummy 'nop' instructions after calling the DSPF_sp_blk_move() function, however I am not convinced that this can be a reliable way of overcoming the inherent problem with the above library function as the nature of the corruption has not been clearly explained.

Is my interpretation of the mentioned error correct? Can anyone suggest a way of handling this corruption problem so that I can still reliably use the DSPF_sp_blk_move() function?

 

Regards...

  • 0
    TI__Mastermind 24340 points

    Hi Cryptoman,

    Cryptoman said:

    At first I thought of using a couple of dummy 'nop' instructions after calling the DSPF_sp_blk_move() function, however I am not convinced that this can be a reliable way of overcoming the inherent problem with the above library function as the nature of the corruption has not been clearly explained.

    Is my interpretation of the mentioned error correct? Can anyone suggest a way of handling this corruption problem so that I can still reliably use the DSPF_sp_blk_move() function?

    Using NOPs as a work around was suggested in the past:

    DSPF_sp_blk_move();
    asm(" NOP");
    asm(" NOP");

    Also, please make sure that you disable interrupts and follow the alignment required for the function, etc..

  • 0 in reply to Mariana
    Intellectual 870 points

    Hi Mariana.

    This is just a quick message for your reference.

    I have integrated the block move command as you have suggested and put the gie enable/disable protection around it. However, it seriously changes the functionality of my existing code. Therefore, I have decided not to use it in my development hereon.

    I am not sure if there is anything else I need to be aware of regarding that function but for the moment I have decided to leave it aside. Nevertheless, I appreciate your assistance regarding this issue.

     

    Regards...

  • 0 in reply to Cryptoman
    TI__Mastermind 24340 points

    Hi Cryptoman,

    I appreciate the feedback.

    Usually if we can not work aroung the assembly function's problems, we suggest that the C equivalent present in the documentation is used, compiled with optimization (-o2 or -o3) in a separate file if needed. Not sure if this helps or not for this function where the C equivalent is very simple, but it is just a suggestion. Please see the C equivalent on page 101 of the:

    TMS320C67x DSP Library Programmer's Reference Guide

  • 0 in reply to Mariana
    Intellectual 870 points

    Hi Mariana.

    I have implemented a very similar function to the C equivalent you have mentioned. However, I have not applied the compiler optimisation to it as you have suggested. I will look into that to see if it makes a difference.

    Thank you for your suggestions.

    Regards...