RAM and FLASH check in microcontroller?

[ricko_uk]

Hi,
a client has put in the software specs that the RAM and FLASH of the microcontroller needs to be checked every time the micro boots.
The micro has not yet been decided but it is going to be a a standard 16-bit or 32-bits micro. The application is not classified as safety critical (their statement/choice and the product is not going to be sold as such).

Few questions:
1) I never implemented any such RAM checks, is there really any need for it both generally (I don't think so) but also in automotive or safety critical applications?

2) I assume the only way to test RAM or any other memory is the classic way to write a value to each location and read it back. How can you implement a RAM check if some of the RAM is going to be used by the OS (freeRTOS) or other resources anyway? Surely you don't want to mess up with the freeRTOS variables... Equally, how can you check if the FLASH is corrupted if you have half of it filled with code?

3) what reasons can I use to convince the client that is not necessary?

Thank you

[ataradov]

1. Yes, there is a real need for safety-critical application. Memory failures do happen. Not all of them may be caught by a simple test, but when the test does catch one, you will be thankful you've implemented it.
2. Do your checks way before OS starts. They need to happen after clock initialization, but before anything else happens. You can write the checking routine in assembly and make it not use the RAM at all, but this is not necessary. Some small amount of RAM would be used by the checking code, and it is fine in most cases.
3. None. It is necessary.

EDIT: Sorry, misread. For a non-safety critical application is is not necessary at all. On the flip side, you can just phone-in the check and make something trivial just to check the box.

But generally, the more checks you can implement the better. It is a matter of how much money you want to spend upfront on trying to catch any hardware issues vs how much it may cost you to recover if 1 out of  a million devices fails in the field.

For automotive applications this calculation is easy, it is way cheaper to do the checks, especially given that you only need to write the procedure once and it gets amortized over many years of use. And getting a recall even on a single car is logistically hard.

If you are making a $20 toaster, who cares?

[ricko_uk]

Thank you ataradov

What about checking the FLASH (I updated the OP after your reply). How do I check for if the flash is corrupted with most of it already filled with the code?

Thank you

[ataradov]

Just the CRC32 of the used part. There is no need to check the unused part at all.

[ricko_uk]

Thank you Alex

[ricko_uk]

BTW, What are some strategies if RAM check fails? Do you just give the user a warning?
Or are there ways to tell the micro to not use those RAM locations?

Thank you:)

[ataradov]

Just fail in a predictable way. Like log/indicate and error in some device-specific way. You can try to recover silently a few times by just rebooting.

Not using is definitely over-engineering.  And some failures will be migrating or affecting many cells. You can't viably ignore them.

As long as the error is indicated in an obvious way, it is good enough.

[bill_c]

I currently have a ATSAMD21G18A that I would like to do memory test on boot and prevent it from operating if errors found, any code examples of how to do this? I searched and didn't find answers.  (sorry if I should have started a new topic)

[ataradov]

I don't have the exact code, it depends on how your application is structured.

Official frameworks have a nasty habit of putting the stack at the end of the user data rather than the end of the SRAM. This will make testing the memory harder. You would need to make sure to either not use stack at all (read write your test routine in assembly), or save the stack pointer, move it to the end of SRAM, run the test, restore the SP.

Then in the reset handler you do something like this:

Code: [Select]

for (int i = 0; i < ((32768 / 4)-20); i++) // reserve 20 bytes for the stack use by the code.
{
  volatile uint32_t *ram = (volatile uint32_t *)0x20000000;
  ram[i] = 0;
  if (ram[i] != 0) error();

  ram[i] = 0xffffffff;
  if (ram[i] != 0xffffffff) error();
}

Add as many tests as you see fit. Often people include running 1s and running 0s, random values. It all depends on your needs. You need to define what specifically you want to prevent.

But generally doing this before high frequency clocks are initialized is not as potent.

But also, D21 is relatively slow, testing SRAM there is somewhat pointless.

[JPortici]

some manufacturers also provide a class-b software library to perform the required checks

[ataradov]

Yes, I think there is a Class-B library for SAMC21, which as far as memory test goes would not be any different from D21. But those libraries are huge and messy to integrate. You can still have a look to get the ideas though.

[macboy]

For FLASH test, if your application doesn't routinely write to the FLASH, then you don't need to test writes, just test reads. So basically, write a small routine to calculate some checksum, CRC, or hash of some kind over the entire program space (don't need to include blank space) and compare to a pre-determined correct value. If it matches, then the FLASH contents aren't corrupted. You've also tested that code executes (it couldn't pass the test otherwise) and that the data bus(ses) that FLASH uses are working.

RAM test is usually pretty easy to include in the very early init code before jumping to the main program, whether that is an actual O/S or just calling a main() routine or whatever.

[ataradov]

Many SRAM weaknesses are only obvious at the full clock. So doing a RAM check at the default clock before other hardware initialization will be useless in most cases.

At the same time, it is the easiest place to check, so if all you need to do is fulfill some requirements, then it is probably fine.

[ealex]

Hello

Take care of the state you leave your RAM after the test.
Got bitten by this once: a version of the rtos had a bug: it determined a warm restart by checking a magic number : 0x5AA5 or something similar.
Their code was "if (ram[0]==0x5A) || (ram[1]==0xA5)" then skip the inital config and jump straight to the task switcher.
The ram test left 0x5A at the end => the rtos thought it was always in a warm-boot scenario and it tried to run tasks from a table filled with 0x5A => the cpu crashed.

And of course this started happening in production, at the end of the assembly line => "a fun weekend"