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.

TMS320F28335 Silicon Errata SPRZ272K - cgtools 6.1.0 must be updated anyway?

The silicon errata sheet SPRZ272K describes two issues:

  • FPU: CPU-to-FPU Register Move Operation Followed By F32TOUI32, FRACF32, or UI16TOF32 Operations, page 12
  • FPU: FPU-to-CPU Register Move Operation Preceded by Any FPU 2p Operation, page 13

The recommendation is to update to the cgtools 6.1.2, so that assembly source code could not generate this issue.
We have no hand written assembly code which could cause this issue, but it is also mentioned, that with that new
version the cgtools take also care about the generated assembly code.

So my question is: do we have to update anyway because the cgtools potentially generate intermediate assembly code which could have this issues? Or could we stay at cgtools 6.1.0 as long as we are taking care about our handwritten
assembly code?

  • Regarding ...

    Philipp Lederer said:
    FPU: CPU-to-FPU Register Move Operation Followed By F32TOUI32, FRACF32, or UI16TOF32 Operations, page 12

    ... cgtools (which include the compiler and the assembler) version 6.1.2 and later can detect when hand-coded assembly has the problem sequence.  I do not think it is possible for the compiler to generate this sequence.  But since I'm not certain, I'll check with some experts and get back to you.

    Regarding ...

    Philipp Lederer said:
    FPU: FPU-to-CPU Register Move Operation Preceded by Any FPU 2p Operation, page 13

    ... You need to use cgtools version 6.2.0 or later to completely avoid the problem.  This cgtools version contains changes that prevent the compiler from generating the problem sequence, and make the assembler able to detect the problem sequence.

    Thanks and regards,

    -George

  • I can confirm that for "FPU: CPU-to-FPU Register Move Operation Followed By F32TOUI32, FRACF32, or UI16TOF32 Operations",
    the v.6.1.0 compiler already inserts the correct number of delay cycles so if you don't have assembly-only files in your compilation, you don't need to upgrade for this issue.