[SOLVED]Self-test strategies for embedded systems

Thread Starter

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
3,063
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?
 

Thread Starter

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,764
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?
 

KeithWalker

Joined Jul 10, 2017
3,063
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?
 

Thread Starter

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.
 

KeithWalker

Joined Jul 10, 2017
3,063
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
21,159
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
548
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
14
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
 

Thread Starter

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
Wrong slave address used
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
3,063
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
542
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.

When you first turn on your new board, start with flashing an LED (or equivalent).
 

Thread Starter

Pushkar1

Joined Apr 5, 2021
416
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.
I agree 100% @KeithWalker
That's why I said in the previous post that I didn't ask the right question
 
Top