ARM Cortex-R5 based Lock-step feature demonstration real time application?

Hi Ravinder,

The Cortex-R5 design provides two external input signals that may be available on your particular Cortex-R5 device:

DCCMINP*[0] Enable comparison error reporting

DCCMINP*[7] Inject an error for testing purposes

DCCMINP*[7] allows error injection to comparators, so this could be another way of testing system reaction to lock-step errors - but I assume this is what you mean by error injection testing logic.

There are other potential options but it will depend on the silicon design. Are you using a Cortex-R5 device from a specific supplier? The reason I ask is that the lock-step comparator logic is often modified by the ARM partner during their silicon design. They may enable other methods of fault injection for testing lock-step. The partner may also modify the debug system for their particular requirements.

One mechanism I can think of is through enabling debug. Debug logic is not replicated for the two cores, so any activity / modification to state via debug functionality to one core will lead to a comparator error. However, in the ARM deliverables example logic is provided that flags an error if invasive debug is attempted while the comparators are enabled. Therefore enabling debug might generate a comparator error through different route.

Placing the Cortex-R5 device near a strong source of radiation will also likely cause errors as bits may be flipped - but this not really a practical solution

If you are using a Cortex-R5 processor from a specific vendor it would be worth asking them if there are ways of easily testing the lock-step operation in their specific design.

Best regards,

Neil.

Hi Ravinder,

The Cortex-R5 design provides two external input signals that may be available on your particular Cortex-R5 device:

DCCMINP*[0] Enable comparison error reporting

DCCMINP*[7] Inject an error for testing purposes

DCCMINP*[7] allows error injection to comparators, so this could be another way of testing system reaction to lock-step errors - but I assume this is what you mean by error injection testing logic.

There are other potential options but it will depend on the silicon design. Are you using a Cortex-R5 device from a specific supplier? The reason I ask is that the lock-step comparator logic is often modified by the ARM partner during their silicon design. They may enable other methods of fault injection for testing lock-step. The partner may also modify the debug system for their particular requirements.

One mechanism I can think of is through enabling debug. Debug logic is not replicated for the two cores, so any activity / modification to state via debug functionality to one core will lead to a comparator error. However, in the ARM deliverables example logic is provided that flags an error if invasive debug is attempted while the comparators are enabled. Therefore enabling debug might generate a comparator error through different route.

Placing the Cortex-R5 device near a strong source of radiation will also likely cause errors as bits may be flipped - but this not really a practical solution

If you are using a Cortex-R5 processor from a specific vendor it would be worth asking them if there are ways of easily testing the lock-step operation in their specific design.

Best regards,

Neil.

Thanks Neil, It is helpful.