[SOLVED]Self-test strategies for embedded systems

Pushkar1

Joined Apr 5, 2021
416
Do you write self-test code to check out fault in your embedded system?

Please share some experience on Self-test strategies for embedded system

Last edited:

KeithWalker

Joined Jul 10, 2017
2,054
Which microcontrollers are you using and what language are you programming in?
Are the self test strategies for debugging the code or detecting future hardware failures?

rsjsouza

Joined Apr 21, 2014
335
Do you know Jack Ganssle? He has some interesting courses and tutorials about better and safer embedded C.
http://www.ganssle.com/

Pushkar1

Joined Apr 5, 2021
416
Which microcontrollers are you using and what language are you programming in?
Are the self test strategies for debugging the code or detecting future hardware failures?
PIC microcontroller & C programming

Do you write self test code for embedded systems?

How do you write code for detecting device failure connected to microcontroller?

atferrari

Joined Jan 6, 2004
4,476
Busy since last April, the OP seems to be preparing a quite complete encyclopedia about programming based on the answers collected in AAC. Lot of chapters...

Or is it a questionnaire to be filled by the end of the semester?

atferrari

Joined Jan 6, 2004
4,476
PIC microcontroller & C programming

Do you write self test code for embedded systems?

How do you write code for detecting device failure connected to microcontroller?

Papabravo

Joined Feb 24, 2006
17,316
Those who can, do; those who can't, teach.
Those who can't do either, administrate.

KeithWalker

Joined Jul 10, 2017
2,054
PIC microcontroller & C programming

Do you write self test code for embedded systems?

How do you write code for detecting device failure connected to microcontroller?
Before I retired, My job was to design automatic test systems for all kinds of products . I wrote the software to run them and did include some self diagnostics to ensure that the test systems were working correctly. The design of the diagnostics varied widely depending on the hardware used in the system, which, in turn, depended on exactly what was being tested. Each case was unique.
How would you go about writing diagnostics for the hardware in an embedded system? What would you think are the most important considerations?

Papabravo

Joined Feb 24, 2006
17,316
1. Controllability
2. Observability

Pushkar1

Joined Apr 5, 2021
416
Busy since last April, the OP seems to be preparing a quite complete encyclopedia about programming based on the answers collected in AAC. Lot of chapters...

Or is it a questionnaire to be filled by the end of the semester?
It's seem some negative criticism for asking programming question.

Pushkar1

Joined Apr 5, 2021
416
1. Controllability
2. Observability
your answer is too short to understand. can you explain it a bit

Papabravo

Joined Feb 24, 2006
17,316
your answer is too short to understand. can you explain it a bit
You can't debug what you can't observe, and you can't fix what you can't control.

KeithWalker

Joined Jul 10, 2017
2,054
It's seem some negative criticism for asking programming question.
Not at all!
If you have a specific question about something that you are working on that you do not understand, we will try to help but we do not belong to this forum to do other people's thinking for them.
What have you learned for yourself so far about self-test strategies for embedded systems?
Is there anything specific that you don't fully understand?

Papabravo

Joined Feb 24, 2006
17,316
You can't debug what you can't observe, and you can't fix what you can't control.
To expand a bit. You need to consider these two things before the first design document is begun. Providing for them is part of the requirements for the whole project and not an after thought. Too many "cost sensitive" systems are specified in such a way that no provisions for controllability or observability are allowed. It is certain that such systems are unlikely to be a success.

click_here

Joined Sep 22, 2020
446
For debugging I always get USART working first, that way I can see values in real time

Next use a "trace macro"

(note that I'm just typing this in from my phone, so excuse any errors)
Code:
#define TRACEINT(iTrace) traceInt(__FILE__, __LINE__, #iTrace, iTrace)

void traceInt(char *fileName, int lineNumber, char *varableName, int valueOfTrace)
{
printf("%s|%d|%s|%d\n\r", fileName, lineNumber, varableName, valueOfTrace);
}
And in the main code

Code:
TRACEINT(i);
I then add one for any other type I'm following (int, bool, ...), put more info in, take some out (for example __FILE__ isn't always needed)

I can see where the values are in the code

ahmaza

Joined Jul 10, 2021
8
Do you mean debugging problem during development?
- this would be solved with debugging tools an strategy
or you mean some sort of system check-up during boot
- most embedded systems have some sort boot-time peripheral and memory checking

Pushkar1

Joined Apr 5, 2021
416
Do you mean debugging problem during development?
- this would be solved with debugging tools an strategy
or you mean some sort of system check-up during boot
- most embedded systems have some sort boot-time peripheral and memory checking
maybe i didn't ask the right question

when you write code I wanted to know how do you guy's write error checking code to debug code for hardware failure

Assume microcontroller is communicating with any I2C device.
There may be such many reasons due to which communication is not happening or can be failure, such as

No pullup resistor on SDA or SCL.
SDA and SCL swapped
no power to slave device
or many other mistakes...

My strategy is that there should be an error code for hardware failure

For example, if the wrong address of the device is given, then the error code should be generate like "wrong address" in a code

Anyway i think i haven't presented question correctly. It's a big topic

KeithWalker

Joined Jul 10, 2017
2,054
All of the examples you gave of "hardware failure" are not failures that would occur once you have the device running correctly. They are examples of errors in assembly and programming. You can test the functionality of the code during de-bugging by displaying variables at suspect places in the code but there is no need to write special error messages as you will be the one de-bugging the code and will be the one who can interpret the results.

Tesla23

Joined May 10, 2009
488
As a general rule you should break the problem down into smaller chunks, and the solution into smaller steps.

If you have designed a board with a controller interfaced to multiple peripherals, your first program should probably be something that exercises each peripheral sufficiently to know that each of the interfaces works correctly. When you have sorted out the hardware / interface bugs, then move onto the next level that makes them interact appropriately. This (probably small) program is also useful at any later stage when you suspect a board level or interface bug.