Errata MSP430F5438A - CPU40 Issue

Hi Christian,

You may need to ask your compiler provider this question.  But I'd be shocked if a compiler ever generated code that would expose this issue.

However, as a word of warning, the linker can cause this problem.  Be sure to link your sections to avoid placing const data immediately after code.  For example, the traditional section DATA16_C should be placed before the traditional CODE section.  Pay special attention to any custom sections you may have or specialized linker settings.

Jeff

Huh, that's a nasty bug.

I doubt it is covered by the compilers, as the datasheet from March didn't list it.

The last isntruction before a constant data section is usually a RET, not a jump, but it is possible anyway. Using a rotate instruction with the PC as destination is however very uncommon. I actually don't know what this could be used for, other than sending the processor into the void.

The only reason why an instruction modifying the PC immediately follows a jmp would be another jump with a different condition. (for <=> branches) But CPU40 seems to apply only for instructions that are single-word, single-cycle instructions. (has to do with the prefetching of the next instruction) Which JMPs aren't. At least I hope so.

Placing a NOP after every jump instruction (the obvious hotfix) is a HUGE impact on size. It's almost as good a workaround as suggesting to not use the MSP.

I have CCSv4.1.3.  I also compile from the command line since all of my code/tools are in a version controlled data base and we use scripts to build.  I have added the --silicon_errata=CPU40 to my command line and I receive an error while compiling that I have a bad argument to option and it says that the arguments should be one of the following {CPU15 CPU18 CPU21 CPU22 CPU23}.  The version of cl430.exe that shows up is v3.2.3.  When I look for updates when I'm in CCS it says everything is up to date.

Hi Philip,

Your version of the CCS code generation tools (CGT) does not have support for the CPU40 issue. You need to use CGTv3.3.0 or later. The CCS update manager should automatically show and update the CGT, but there seems to be a bug - I just verified this on my PC with the same version that you have. Now there are two options:

1. You download and install the latest CCS version (BTW, we'll release CCSv4.2 next week, it handles all CPU bug workarounds automatically - no need to add strings to the command line)

2. You update your current version. If you do so, the current version of the CGT will be replaced by the latest one. If you don't want to do that, please go with option 1. As mentioned, there seems to be a bug in the updater utility that doesn't automatically install the latest CGT, but you can still trigger the update manually:

1. Click HELP --> SOFTWARE UPDATES --> FIND AND INSTALL...
2. CCS will show the update dialog. Please select SEARCH FOR NEW FEATURES TO INSTALL and clock NEXT (see screenshot)
3. In the next step you need to make CCS look for new CGTs, therefore select CODE GENERATION TOOLS UPDATES and click NEXT (see screenshot)
4. CCS will now list all available updates. Please check the MSP430 CODE GENERATION TOOLS 3.3.3 (as shown below) and click NEXT
5. Accept the License agreement
6. Start Installation by clicking FINISH in the last step

Hope this helps!

Regards,
Markus

Marcus,

When you said:

it handles all CPU bug workarounds automatically

does that include good old CPU4 ?

Specifically, when I use "push #4" or "push #8" on chips without CPU5 bug, what machine code do I get?

--OCY

Marcus,

When you said:

it handles all CPU bug workarounds automatically

does that include good old CPU4 ?

Specifically, when I use "push #4" or "push #8" on chips without CPU5 bug, what machine code do I get?

--OCY

Hi OCY,

Sorry in case I wasn't clear. We ensure that our tools taking care of critical CPU errata (this also includes CPU4, but not CPU5 as it was fixed in silicon in an early state). In some cases, we don't want that workaround applied to all devices of a CPU family. Therefore, we introduced a feature in CCS (and IAR) that allows automated setting of compiler flags for:

• CPU15
• CPU18
• CPU21
• CPU22
• CPU23
• CPU40

Some of these workarounds just generating compiler warnings, when you write assembly code, as most the the above items don't even affect the C compiler.

Does this answer your questions?

Regards,

Markus

Markus,

It was me that wasn't clear.

I known that both CCS and IAR (as well as many other compiler/assembler) will "automatically take care of CPU4 bug". They all generate 2-word 5-cycle instructions (instead of 1-word 3-cycle) for push #4 or push #8.

There are lots of members in the MSP430 (and MSP430X) family that do not have the CPU4 bug. However, at far as I know, the currently released compiler/assembler will still "automatically" generate these long and slow code to work around that non-existing bug when those members are being used..

My question is, will the newer version of tools "automatically" not work around a hardware bugs when that bug is not in the particular member being used?

--OCY

Hi OCY,

Yes, you are correct - the workaround is always on (also with the new version). You have a point that this is something that could be automated as well.

I'll discuss with the team to drive this further.

Regards,

Markus

Hi,

Where can I find the details about "CPU22",

the errata sheet doesn't mention anything about this issue,

and it seems that IAR compliler has no workaround on this errata.

Thankyou and Regards.