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.

RM46x Silicon Errata Severity level

Other Parts Discussed in Thread: RM46L430, HALCOGEN

Hi,

One of our cusomter is using RM46L430 device in their new product
and we have few basic questions about the errata document(SPNZ200A).

1> Severity
Most of the Errata Severity level is "3-Medium".
Could you please let me know what is the meaning of this Severity level.
In case of "3-Medium" should we consider it as Mandatory?
and in case of "4-Low" should we consider it as optional?

2>CORTEX-R4 related Errata
There are around 10 "CORTEX-R4" related errors,
can we assume that CORTEX-R4 related Errata is taken care by the Compiler
and there is no need to worry in the user application?

Regards
Prad

  • Hi Prad,

    1> Severity

    Most of the Errata Severity level is "3-Medium".
    Could you please let me know what is the meaning of this Severity level.
    In case of "3-Medium" should we consider it as Mandatory?
    and in case of "4-Low" should we consider it as optional?

    >> For all errata classified as being of medium severity, we do recommend to implement any suggested workaround.

    >> Errata classified as low-severity are either for your information only or the likelihood of the issue occurring is "extremely low". In this case, the application designer can choose to implement any suggested workaround to handle the odd chance of running into the condition in which the issue occurs.

    2>CORTEX-R4 related Errata
    There are around 10 "CORTEX-R4" related errors,
    can we assume that CORTEX-R4 related Errata is taken care by the Compiler
    and there is no need to worry in the user application?

    >> Our GUI-based code generation tool (HALCoGen) generates initialization routines that also include function calls to handle Cortex-R4F related errata. These are not automatically included by the compiler and need to be addressed by the application.

    Regards,

    Sunil

  • Hi Sunil,

    Thank you so much for the information
    and I am sorry for the delay.

    Could you please answer an additional question on the errata.

    SYS#102:
    The errata mentions that there is a TYPO in the manual and the
    EFUSE_Abort[4:0] of the SYSTASR register should be read-clear.

    With the next version of document/device will the manual be modified
    stating as "read-clear" or else the device silicon will be changed to make write-clear?

    We would like to know which is the correct one in terms of the device(RM46L430) operation.

    Best Regards
    Prad

  • Hi Prad,

    This field remains as a read-to-clear field even though the specification indicates it to be a write-in-privilege-mode-to-clear field. This bug is not being corrected in silicon and will remain as part of the errata.

    We will also need to internally decide whether to keep the reference manual as-is, or update it to reflect the actual implementation. I will keep you posted.

    Please close this forum thread and open a new one for this SYSTASR issue.

    Regards,

    Sunil