MCU diagnostic tricks

[Chibouraska]

Hi,

I would like to know if CCS has some built in functions that i could use to secure embedded software, by that i mean ROM and RAM tests, errant code recovery etc.

I use the wdt but this alone is not enough. If someone has a good tutorial about it, and CCS should have some good algorithms for this purpose, i think it would set them a part from the competition.

If they had these functions that we could use. Thanks a lot.

AC
---------------------
_________________
think a bit at the time

[Ttelmah]

Key to the watchdog, is design and thought.
It has a lot in common to a safe, but just as with a safe, it does you no good at all if you leave the key lying around.
Unfortunately, this is the commonest way you see it used, with things like the option to restart the watchdog in delays, meaning that the restart instruction, is sitting completely 'unprotected' in the code. Used like this, the watchdog, will recover from a completely hung processor, but from almost nothing else....
The point is that the number of locations where 'restart_wdt' exists, should be kept to an absolute minimum, and the code should be written so these can only be reached if things _are_ working correctly. So (for instance), tests that the important routines _have_ been called since the last time this part of the code was reached, which must 'pass' before the watchdog will restart. I use bit flags, which are toggled in routines, and must have changed or the restart won't be called.
Unless you test like this, you have no proof that the 'real' program flow is working, and code could just be doing a 'drunkards walk' though memory, and accidentally hitting the restart_wdt instruction...

On data, you can checksum structures and arrays. I commonly do this for structures holding values that must be correct for the code to work correctly.
Other thing you can do, is extend arrays by just two bytes. One in front of the array, and one after. Fill these with 'marker' values, like 0xAA, and when you have updated the contents, check the markers are still intact. You can also check before using the values. This way any overrun in the array pointer _or in another array_, will be flagged.

Best Wishes

[Chibouraska]

Ttelmah hi, ok how to manage that a rogue program will issue a WDT timeout ? This is what we are taking about here, but the art of the watchdog lies in ability to place the restart_wdt at less possible places as to ensure a rogue program won't kick the dog accidentally that makes a
lot of sense.
Q.: but how can we protect the system from a rogue program changing the watchdog registers. I found this article very interesting.
http://www.ganssle.com/watchdogs.htm
I guess many of you read it, if not it's a very good article, the basics of what we are talking here is explained. In the article it talks about the characteristics of a great watchdog and one point says

[Ttelmah]

This comes down to using an external watchdog, not the internal one. I often do this with one of the power management IC's, that controls reset on the chip. Then the chances of an accidental watchdog access become much lower, and (of course), the physical reset puts all registers into the reset state.
Remember you must ensure that your _hardware_ fails safe. So things like all signals are biased to safe states with resistors, if not actually driven by the IC.

Best Wishes

[Chibouraska]

Thanks a lot for all these pointers, but does reset_cpu() in PCD compiler
put all registers into a reset state? thx

AC
---------
_________________
think a bit at the time

[Ttelmah]

No.

Best Wishes

[Chibouraska]

I have made up a scheme to implement what M. Ganssle explains in the article and it looks like this.

[Ttelmah]

No, you are not using the watchdog at all.
This is just code checking. Reasonable, but will do nothing if (for instance)the code gets into a locked state.

Best Wishes