best practices for error handling?

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

best practices for error handling?

439 Views
irob
Contributor V

Hello all, just another big picture question for you pros.  How do you all handle errors with your 8-bit projects?  I do a lot of RS232 / SCI based boards and also interface with I2C sensors and memories.  Just curious what level of error handling you all do with these types of I/O.

 

Any point to it, if no RTOS is required?  How do you handle a failed CRC?  Log it and retry?  Thoughts?

Labels (1)
0 Kudos
2 Replies

263 Views
Lundin
Senior Contributor IV

If you have logging possibilities, then by all means do so, but that isn't common on most 8-bit applications though. Normally you would just discard all corrupt packages you encounter and try again.Verify the protocol, but also check for overrun, framing errors etc. A robust embedded system is one that finds a lot of errors - and ignores them in a controlled manner.

 

One simple way is add a plain, red error LED to the PCB and light it whenever an error is encountered. That way you can at least spot continuous communication errors, even though you can't tell their nature without further troubleshooting. What level of error indication you should have/can afford depends on the nature of the application.

 

0 Kudos

263 Views
PG1
Contributor I

Well there are design errors during development and hardware errors that can occur at anytime.

 

Example of design error- passing bad arguments to a function

 

Example of hardware error-  crystal fails to start at low temps due to manufacturing or purchasing failure.

 

For software development errors, I include code to check all parameters passed to a function. The code is surrounded by conditional macro such as

 

#if BUILD_TYPE==DEBUG_BUILD

if (PARAMETER_IS_NOT_EXPECTED)

reset(DESIGN_ERROR_1)

#endif

 

reset halts the program and lets you know where the error was encountered

 

 

When the RELEASE BUILD is built, this code is not included, presumably because exhaustive checking has already been performed.

 

 

For Hardware Errors, I depend on having a working watchdog timer and a hard error routine. Example:

 

if (ICS_FAILS_TO_CHANGE_FROM_INTERNAL_OSC_TO_CRYSTAL_OSC)

reset(CRYSTAL_FAIL);

 

 

reset  can put an error CRYSTAL_FAIL on the LCD, wait a little, and go into an infinite loop so the WDT does a silicon reset. (The controller continues to run on the internal oscillator).

 

 

0 Kudos