Cortex M0 internal Failure solution for ALU, CPU and Register rong results

Thanks for the info.

Solving the issues is the next step.

I want to know if this issue can occur? Under what scenarios it can be produced (if randomly).

Can this be 1.detected 2.alarmed 3.solved by some means  using SW algorithms or Hardware?

Let say if ALU stuck can happen if core supply drops to 0 or high in very quick time(neon Sec). Then this can be handled using

- HW by avoiding sudden voltage drop or peaks.

- SW algo of filters

Thanks

Hello,

regarding

I want to know if this issue can occur? Under what scenarios it can be produced (if randomly).

I can not say it would never happen but it would be very rare case.

ALU wrong results, wrong value reading registers or memories would be occurred by an unstable voltage or influence of a radio waves.

To prevent them would be responsible to outer core (i.e. Cortex-M0) logics.

Are you in the situation which you can design microcontroller of which core is Cortex-M0?

If it is so, you can equip ECC or parity for the memories.

Regarding the ALU or registers, you should implement such mechanism into the core.

However, I don't know it would be possible under the normal processer license.

Best regards,

Yasuhiko Koumoto.

Hello Yasuhiko,

Can ECC mechanism handle register related issues also?

or only issues related to memory?

Thanks

Shashi

Hello Shashi,

if you have the architecture license, then it might be possible to implement ECC for registers. However, for such purpose, the triple structure F/Fs will be used. Probably it would be the normal implementation.

Best regards,

Yasuhiko Koumoto.

Hello Shashi,

if you have the architecture license, then it might be possible to implement ECC for registers. However, for such purpose, the triple structure F/Fs will be used. Probably it would be the normal implementation.

Best regards,

Yasuhiko Koumoto.

Something looking like EEC logic on small internal blocks like the registers is likely to add more gates than the size of the logic it is trying to monitor. Given the mostly likely cause of this type of random failure is either power supply glitches or a device on the threshold of being just within tolerance, any extra logic will be impacted too, and adding more logic is statistically likely to make the problem worse not better. "Failure monitoring" only really helps when it's monitoring quite big blocks ...