• State TI Thinks Resolved
  • Locked Locked
  • Replies 10 replies
  • Answers 3 answers
  • Subscribers 102 subscribers
  • Views 2408 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

TMS320C6655: Errata clarifications required

Michael Shklyarman
Genius 12245 points
Part Number: TMS320C6655
Other Parts Discussed in Thread: TMS320C6670, SYSBIOS

Champs,

Customer requires clarifications wrt few c6655 device errata:

1. Advisory 13: Single MFENCE issue. Customer does not have any assembly code of their own, uses IBL version 1.0.0.14, and the TI compiler version v7.4.11. Has this issue been taken care of in is these versions?

2. Advisory 14: Read Exception and Data Corruption Issue. Question: Is TI platform SW supposed to take care of disabling PFX bits in MARs 12-15? If not - where this should be done (boot loader/application startup)?

3. Usage Note 13: Revised PLL Programming Sequence Usage Note. Customer code is based on TI IBL version 1.0.0.14 Nov 2011, and application code makes use of  CSL Revision: 01.00.00.05. Can you confirm if this usage note is implemented in the above versions?

thank you!

Michael

  • 0
    TI__Guru**** 161600 points
    Hi Michael,

    Which SDK version is this? In general Errata Advisories should be taken care of in the SDK releases, I'm looping the sw team to elaborate.

    Best Regards,
    Yordan
  • 0
    TI__Guru** 114410 points

    Michael,

    I assume since the customer is using IBL version from NOV 2011 that they are using the MCSDK baseline and not Processor SDK RTOS. If you have the exact MCSDK version then we may be able to track this better from the release notes. The last version of MCSDK 2.x released in August 2012.

    I will check internally and see if we can dig the history on these fixes implemented in the IBL.

    Regards,
    Rahul

  • 0 in reply to Rahul Prabhu
    TI__Guru** 114410 points

    Mike,

    From the release notes I found that IBL 1.0.0.15 that was part of  MCSDK 2.1.2.5 and MCSDK 2.1.2.6 had the PLL sequence finally updated. Here is the release notes for the MCSDK version:bios_mcsdk_releasenotes_02_01_02.pdf

    Regards,

    Rahul

  • 0 in reply to Rahul Prabhu
    TI__Guru** 114410 points

    The CSL (mfence and prefetch) were added in CSL_cacheAux.h file. Earlier user had to do the mfence and prefetch operations, with the update in CSL, he can directly call cache operations (e.g. CACHE_invL1d, CACHE_wbL1d etc). The CSL implements the “advisory 6”.

    This update was tracked as fixed in early version of Processor SDK RTOS for Keystone I device so unlikely that it is in the IBL version used by the customer but the customer can use the CSL_cacheAux.h to see if their implementation has this fix. I have attached the file for reference.

    csl_cacheAux.h

    Hope this helps.

    Regards,

    Rahul

  • 0 in reply to Rahul Prabhu
    TI__Genius 12245 points
    Hi Rahul,

    I am not sure I fully understand the mechanism of the advisory 14 fix. The CACHE_invL1d for example invalidates all pre-fetch buffer content and XMC blocks all requests until prefetch buffers are idle. At the same time the workaround for advisory 14 calls for disabling PFX bits in MAR register for the affected address range. It is possible that invalidating prefetch buffers would eliminate some circumstances where the issue can arise but based on the information available in the datasheet/errata it does not look like an ultimate fix. I would greatly appreciate a clarification here.

    Also, with regard to advisory 13 - I see _mfence being used in the cache control operations but the advisory explicitly calls for 2 mfence calls back to back as a workaround. it is possible that the compiler converts the _mfence() call into two mfence commands but I was not able to find evidence of this...

    thanks
    Michael
  • 0 in reply to Michael Shklyarman
    TI__Genius 12245 points

    Hi Rahul,

    I believe advisory6 referred in the code (CACHE_invL1d() function in csl_cacheAux.h) implements the fix for the advisory 6 from TMS320C6670 Errata:

    Potential L2 Cache Corruption During Block Coherence Operations Issue. 

    Advisory 14 in C6655 errata is called "Read Exception and Data Corruption Issue". It is not the same thing. Moreover, the C6670 Errata also contains advisory 33 named "Read Exception and Data Corruption Issue" and the description seems identical to the Advisory 14 in C6655, so it is definitely two separate issues. I would really appeciate your help clarifying the status and fixes of "Read Exception and Data Corruption Issue" advisory in the Keystone 1 family.

    thanks

    Michael

  • 0 in reply to Michael Shklyarman
    TI__Genius 12245 points
    Hi Rahul,

    Any update on this?

    thanks
    Michael
  • 0 in reply to Michael Shklyarman
    TI__Genius 12245 points
    Hi Rahul,

    I believe I figured out the mfence question - the _mfence() found throughout pdk code is an intrinsic, so compiler would not generate it on its own unless explicitly called.
    On the SYSBIOS side the mfence is used in the cache wait function which in the newer SYSBIOS actually implements the 2xmfence workaround for the errata (refer to Cache_wait() function in c:\ti\bios_6_46_04_53\packages\ti\sysbios\family\c66\Cache.c.).
    So there is no risk of mfence showing up in application code unless the intrinsic is called and if there is a need to use mfence the application should call it twice as in Cache_wait() to work around the erratum.

    This leaves only the Advisory 14 "Read Exception and Data Corruption Issue" question. I have not been able to find in platform code any traces of a fix that is recommended as a workaround (disable the PFX bits in the MARs for address ranges 0x0C000000 –
    0x0FFFFFFF corresponding to cacheable data)
    Your guidance will be greatly appreciated

    thanks
    Michael
  • 0 in reply to Michael Shklyarman
    TI__Genius 12245 points

    Hi Rahul,

    I did some further research but am not able to find any fixes for the Advisory 14. It looks to me that this is customer's responsibility to implement the workaround if the advisory applies to their design. I will greatly appreciate you confirming this understanding.

    thank you

    Michael

  • 0 in reply to Michael Shklyarman
    TI__Guru** 114410 points
    Michael,

    Sorry for the delay in getting back on this issue. I am trying to work with internal experts and finding the background for this errata. This is not a typical usecase for DSP bare-metal or RTOS software so I doubt if this work around is implemented in the SDK but I will update the thread as soon as I here from the design/system expert.

    Regards,
    Rahul