• State Resolved
  • Locked Locked
  • Replies 20 replies
  • Answers 1 answer
  • Subscribers 32 subscribers
  • Views 4996 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.

memset/memcpy doesn't set/copy the whole memory

Christian Fuchs1
Expert 1260 points

Other Parts Discussed in Thread: TMS570LS3137, HALCOGEN

Hi! I'm using TMS570LS3137 with CCSv5 and Compiler 5.0.6. I've defined an byte array in external SDRAM and I want to fill it with memset. After the memset function has finished I can see that not the whole array has been filled. In my case always Byte 76-79 stay at the old value. If I put this array to internal RAM it works fine. Also if I put it in external SDRAM and align it to a 8 Byte boundary it works also. I've also tried to set a watchpoint at the address of byte 76, but then These 4 byte gets filled correctly and the error occurs at another address. memcpy behaves the same. What's going wrong there? Thank you and BR Christian
  • 0
    Intellectual 410 points

    Hi,

    the problem description perfectly fits to DEVICE#B064 bug, see SPNZ193D.

  • 0 in reply to Jan Nárovec
    Expert 1260 points
    Hello,
     
    thank you, I've never thought of a silicon bug.
     
    BR
    Christian 
  • 0 in reply to Christian Fuchs1
    TI__Mastermind 49120 points

    Christian,

    Sorry for the inconvenience. There is an additional update to this bug's description. There is no dependency on the alignment of the first address of the store-multiple instruction. Essentially, you need to avoid writing to external memory using a store-multiple instruction. All writes to external memory must be done using single store instructions (STRxx).

    Also, the external memory must not be configured to be of "normal" type. Configuring a memory as "normal" type allows the CPU to "merge" multiple single stores into a write-burst, so the issue could occur again.

    We are currently updating the errata documents to include this description.

    Regards, Sunil

  • 0 in reply to Sunil Oak
    Expert 1260 points
    Sunil,
     
    Thank you for the information.
    I've two additional questions:
    1) How do I configure my SDRAM to other than "normal" type? In TRM I can find a "strobe mode" only for async. memory.
    2) How can I avoid that the compiler uses store-multiple instructions (we uses C and C++ source code). Is there a compiler switch for that?
     
    Thank you
    Regards
    Christian
  • 0 in reply to Christian Fuchs1
    Expert 1260 points
    And what's about DMA access to external RAM? Is this also affected? Regards Christian
  • 0 in reply to Christian Fuchs1
    TI__Mastermind 49120 points

    Christian,

    DMA transfers to external memory are not affected by this issue.

    Regards, Sunil

  • 0 in reply to Christian Fuchs1
    TI__Mastermind 49120 points

    Christian,

    1) How do I configure my SDRAM to other than "normal" type? In TRM I can find a "strobe mode" only for async. memory.

    >> You need to configure the MPU inside the Cortex-R4F CPU to define the external memory address range as a "device" type or "strongly-ordered" memory region.

    2) How can I avoid that the compiler uses store-multiple instructions (we uses C and C++ source code). Is there a compiler switch for that?
    >> We are currently working on a compiler patch that will prevent the generation of store-multiple instructions. This patch is currently in alpha-testing and we expect to make it generally available by the end of this month.
    Do you use the TI CodeGen Tools to compile your C/C++ source code?
    Regards,
    Sunil
  • 0 in reply to Sunil Oak
    Expert 1260 points
    Sunil,
     
    thank you for the informations.
    I've one additional question to memory type:
    Do I have to enable MPU to change memory type? Or can I only change the type in HalCoGen and nothing else?
     
    Thanks in advance
    BR
    Christian 
  • 0 in reply to Christian Fuchs1
    TI__Mastermind 49120 points

    Christian,

    Yes, you have to enable MPU in order to configure the attributes of any given memory. You can generate the code to configure the MPU using HALCoGen. Then you still need to call the mpuInit() function from your source code.

    Regards, Sunil

  • 0 in reply to Sunil Oak
    Expert 1260 points
    Hi Sunil,
     
    you wrote that TI is working on a compiler which prevents the generation of store-multiple instructions and plan to release it by end of December 2013.
    Is it already released? What is the version number?
     
    Thank you
    Regards,
    Christian
  • 0 in reply to Christian Fuchs1
    TI__Mastermind 49120 points

    Hi Christian,

    Yes, version 5.1.3 is the latest version available. This version supports a "--no_stm" compile option that prevents generation of STMxx instructions for any writes to memory. You need to be careful and enable this option only for source files that have writes to external memory.

    You can get this version of the compiler from inside CCS by checking for updates on installed components.

    Regards, Sunil

  • 0 in reply to Sunil Oak
    Expert 1260 points
    Hi Sunil,
    again a question: How can I recompile the rtsv7R4_A_be_v3D16_eabi.lib with the new compiler option. Especially memcpy and memset functions I need without the STMxx instructions.
    What happens if I enable this option for files without writes to external memory?
    Thank you
    Regards,
    Christian
  • 0 in reply to Christian Fuchs1
    TI__Mastermind 49120 points

    Hi Christian,

    There are new versions of the memcpy and memset functions. These are called no_stm_memcpy and no_stm_memset respectively, and are called instead of the original functions when the "--no_stm" option is selected.

    This option disables the generation of STMxx write commands regardless of which memory is being written to. This would result in a loss of performance in case the writes are happening to the CPU's tightly-coupled SRAM.

    Regards, Sunil

  • 0 in reply to Sunil Oak
    Intellectual 370 points

    Hi Sunil,

    we are seeing these issues using IAR and RM48.

    You say in January the only fix was to use CCS with --no_stm option; but only for code associated with external DRAM, using this across the board throttle performance with respect to internal SRAM.

    So assuming we use CSS and your mempcy library implementation. Does this use stm for internal RAM accesses and avoid STM's for DRAM accesses? 

    More importantly is a silicon rev now available that fixes this bug?It is now October and your last post was in January. If no fix is available; when is fix planned for?

    Kind Regards,

    Owain

  • 0 in reply to Owain Phillips
    TI__Mastermind 49120 points

    Hi Owain,

    The "--no_stm" option is a file-level directive for the compiler to use multiple single-store instructions instead of a set of store-multiple instructions.

    You should enable this option only for source files that have functions that write to external memory. The other source files should continue to be compiled without any limitations as before.

    A silicon fix is expected soon. We can confirm a schedule once the validation activity is completed. This will be close to end of November 2014.

    Regards, Sunil

  • 0 in reply to Sunil Oak
    Intellectual 370 points

    Hi Sunil,

    Can you please confirm that you are verifying the silicon fix at the moment and that you will have a date for production silicon at the end of November.

    Assuming the tests are good when can we expect to see fixed silicon?

    Kind Regards,

    Owain

  • 0 in reply to Sunil Oak
    Intellectual 370 points

    Hi Sunil,

    Can you please confirm that you are testing the fixed silicon at the moment and that you will  have a date for production quantities at the end of November assuming those tests are positive.

    So wherever data structures are placed in SDRAM we must ensure these accesses not pipelined write accesses. This means to stacks and no STM instructions. Is this good enough to avoid the problem? I assume your library memcpy implementation still uses STM for internal RAM, but other instructions when copying in SDRAM.

    Kind Regards,

    Owain

  • 0 in reply to Owain Phillips
    Intellectual 370 points

    Also does this bug exist in the TMS570?

    A possible solution for us may be to switch from RM48K to TMS470 if this silicon does not exhibit the same bug.

    Kind Regards,

    Owain

  • 0 in reply to Owain Phillips
    TI__Mastermind 49120 points

    Owain,

    We will receive silicon with the fix close to mid November, hence the end of November date for when we can confirm that the issue is corrected.

    The issue does affect EMIF on the TMS570LS31x/21x/12x/11x MCUs as well.

    Regards, Sunil

  • 0 in reply to Sunil Oak
    TI__Mastermind 49120 points

    Missed an earlier question:

    "So wherever data structures are placed in SDRAM we must ensure these accesses not pipelined write accesses. This means to stacks and no STM instructions. Is this good enough to avoid the problem? I assume your library memcpy implementation still uses STM for internal RAM, but other instructions when copying in SDRAM."

    Yes, you need to ensure that there are no burst writes (combination of STM instructions) to external memory. There are additional memcpy and memset routines in the rts library which do not use the STM instructions. These new routines are included instead of the regular ones when the --no_stm option is enabled for that source file.

    Regards, Sunil