C51 data memory test

Yes - quite possibly so.

But an Aerospace company should have an established way to deal with this...

Yes - quite possibly so.

But an Aerospace company should have an established way to deal with this...

Thanks guys for all the insight. I agree that an Aerospace should have the requirements in place and allow engineers to work toward meeting them but the situation is not like that where I work. The reason I posted the question in the first place was to get a consensus among us firmware engineers and I already got that.

I agree that an Aerospace should have the requirements in place and allow engineers to work toward meeting them but the situation is not like that where I work.

So in a nutshell, you're trying to determine just how far in over your head you are with this project. Well, the answer is pretty obvious by now: you're in way over your head.

I might be but the consensus told me others might not be far off!

An important aspect here is that whenever external memory is involved, there is the probability of bad solder joints. So it is always good to try to scan all signals that can be scanned to verify correct connectivity.

But the problems are huge.

For example - you turn on the equipment when it is cold. A test when cold does not tell the behaviour after it has been running for a while and reached the steady-state temperature.

Next thing is that smaller microcontrollers often uses 3V3 or 5V and often have most external equipment run with same voltage. More high-end processors normally use multiple voltages. So a very low voltage for the CPU core. A higher voltage for the GPIO signals. A third voltage for the RAM chips. Now, you suddenly got more problems. The reliability of the RAM depends on it getting the correct voltage. With too high voltage, it may get overheated and start to misbehave after a while. With too low voltage, it may run too slowly resulting in too small timing margins resulting in random bit errors. And with incorrect interface voltage between processor and memory you may get incorrect sampling of the high logic level.

So in the end, you have a situation where a startup test often may have a very limited value except to find blatantly broken hardware. In real life situations, safety critical equipment needs to perform constant supervision while delivering the live service it is designed for. So you need to store checksums for all data structures you can get away with and constantly scan through them to verify that they are correct. This not only verifies memory integrity but also verifies that you don't have any bad pointer accesses resulting in memory corruption. After all - the majority of failures an end user is likely to see are from software errors unless you have fouled upp the oscillator or power supply + filtering design.

Obviously, tests designed to run concurrently with the normal operation can't perform any memory tests according to any by-the-book factory tests. You will have to investigate all hw parts and all software modules and create a testability document where you figure out how a running equipment can get a reasonable confidence that everything works as expected. And you will have to figure out what external hardware (watchdogs or whatever) you may need to produce reasonable error messages to the end user in case the system is so broken that it can't perform the normal self-tests and present normal error messages.

A question here is what courses or past experience you have in writing this type of software, where it isn't just enough to make sure an RTOS always manages all required deadlines but where you also needs to supervise all individual actions and all produced output signals and if possible double-check all input signals.

In the end, the device (if the standard so requires) must be designed so that it really doesn't matter how bad the processor or any other hardware is. But the system should either stay pitch black or present a clear error indication in case it can't produce the normal results with the required confidence. Or, for some standards, it may continue to produce results but must then clearly indicate that there are confidence problems.

Are you the only software developer? Note that many of the standards involving human safety are not just happy with "we are doing" but also requires you do produce huge amounts of documentation about all your design steps, reasons for decisions etc, etc. So if you are stuck right now about memory tests, you might get seriously more stuck a while later when the company have invested more money into the product and the reviews redflags your development process, the design, the documentation, the testing, ...

In Short. It is unlikely that you will be able to do the Memory Test using C.
You would need to be very knowledgeable about how the compiler uses memory to convince it to do what you want to do, if it is even possible. The Keil Compiler does not use a real parameter stack. You can not just change the stack pointer. You could Test the PDATA and XDATA areas if you chosse the correct memory model.
For the 256 byte internal memory ASM is the way to go.

Thank you all.