4
\$\begingroup\$

One of my older prototypes for Super OSD always had one little bug. A single pixel in the video, about midway in the frame would always be off. It did not really affect anything as most pixels normally stayed in the off mode, but it was noticeable during test patterns. I could never narrow down what the cause was.

Thinking about it now, could it have been a failed bit in the memory array? Is this at all common with MCU's with SRAM? The prototype was not abused: a fixed +3.38V (within the rated 3.0V - 3.6V), room temperature operation, minimal load on the outputs. It was a dsPIC33FJ128GP802.

I'm designing a new prototype now and I think it's the same chip as I used last time, so I will see if the problem occurs again. Does anyone know if it is prudent to run a "memory test" on a chip?

\$\endgroup\$

4 Answers 4

Reset to default
4
\$\begingroup\$

yes, they can, but any decent programmer verifies programming.

This is normally done by taking a check-sum of the program. I would actually guess that if it is repeatable, I would reprogram just to be sure, and if it is still repeatable your software is has a small bug. This type of bug can be hell to find.

To check ram, you need to write test characters and read them out, one byte at a type and see if it fails to match.

\$\endgroup\$
12
  • 2
    \$\begingroup\$ please note when I say programmer, I mean the device and the program you use. \$\endgroup\$
    – Kortuk
    Commented Nov 17, 2010 at 2:28
  • 4
    \$\begingroup\$ The programmer validates the ROM, but it doesn't validate the RAM. You'd need to write a program which does a RAM test, ie writing the usual patterns, all 1, all 0, mixed, and checking to ensure that they're retrievable. \$\endgroup\$
    – gorilla
    Commented Nov 17, 2010 at 5:15
  • 1
    \$\begingroup\$ Kortuk, that is flash memory - I'm talking about RAM. \$\endgroup\$
    – Thomas O
    Commented Nov 17, 2010 at 10:14
  • \$\begingroup\$ You might want to read his comment again. \$\endgroup\$
    – Mr. Hedgehog
    Commented Nov 17, 2010 at 13:01
  • \$\begingroup\$ Okay, here's a related question: assume the MCU was fully checked at the factory, and assuming the memory actually had a bit error: what would cause this? \$\endgroup\$
    – Thomas O
    Commented Nov 17, 2010 at 13:15
2
\$\begingroup\$

It is always prudent to do memory checking. I typically put a simple memory test routine as part of the startup sequence for my firmware code. While a full-blown test can take a longer time depending on the memory size, a faster test can be done to catch major errors.

This article at embedded.com has a good explanation and some example code on how to do simple memory testing on an embedded device.

\$\endgroup\$
3
  • 1
    \$\begingroup\$ For a small embedded processor if your memory is permanently damaged in any way you are going to be hosed. There is no way you could do full memory verification and avoid damaged sections without drastically slowing down code and ballooning it's size. The easy way to fix transient bit errors is with watchdog, illegal address access, and illegal opcode resets. \$\endgroup\$
    – Nick T
    Commented Nov 17, 2010 at 18:56
  • 1
    \$\begingroup\$ I don't know why you bring up "avoid damaged sections". We're talking about detecting permanently damaged RAM. if no damage is detected, then the code runs just as fast and has practically the same size as the original code. If even a single bit of damage is detected, then presumably the code would somehow indicate the problem and halt, and \$\endgroup\$
    – davidcary
    Commented Jan 2, 2011 at 5:38
  • \$\begingroup\$ I don't know why you bring up "avoid damaged sections". We're talking about detecting permanently damaged RAM. If no damage is detected, then the MCU can be re-programmed with the original code with the original size and speed -- or perhaps the developer will make it a few lines longer to test the RAM every power-up; after that test, the rest of the code runs at the original speed. If even a single bit of damage is detected, then presumably the code would somehow indicate the problem and halt, and the developer would throw away that chip and get a replacement. \$\endgroup\$
    – davidcary
    Commented Jan 2, 2011 at 5:44
2
\$\begingroup\$

It is also good to observe that for memories (DRAM, SRAM) transient bit errors are typically some orders of magnitude more likely than permanent errors. Checksums are not effective against transient bit errors, so in order to tackle these error detection and correction (EDC) is required.

The good news for non-safety related systems with a small amount of RAM the failure rates are still fairly low (500-5000 FIT per Mbit).

\$\endgroup\$
1
  • 1
    \$\begingroup\$ Most likely a program bug. But stuck-at faults are not completely impossible. I hear rumors that practically all DRAM has at least one or two permanent errors; but the chip tester detects the errors, and blows the fuses to disable the bad/rows columns and subsitutes spare rows or columns (or both). Perhaps somehow your chip, like many/most chips, had such a failure, but it somehow got around the test machine that is supposed to keep such chips from escaping the factory. Or perhaps ultra-high-energy cosmic ray damage. en.wikipedia.org/wiki/… . \$\endgroup\$
    – davidcary
    Commented Nov 18, 2010 at 5:25
0
\$\begingroup\$

Highly unlikely. On-chip memory on MCUs doesn't fail. RAM tests are only needed for external RAM. Far more likely it is a code problem putting something in RAM where it shouldn't - bad pointer etc.

\$\endgroup\$
3
  • 4
    \$\begingroup\$ Heh, at the Aluminium smelter we had to checksum the data structures in ram continuously for single bit errors. The watchdog reset the MCU if the stack or registers got bent. 169000 Amperes has a way of making itself felt nearby. \$\endgroup\$
    – Tim Williscroft
    Commented Nov 18, 2010 at 0:59
  • \$\begingroup\$ @Tim: Sounds like that would call for a solid mu-metal box before anything too extreme \$\endgroup\$
    – Nick T
    Commented Nov 18, 2010 at 5:30
  • 4
    \$\begingroup\$ Noooo the eddy currents would make it hot. A wire longer than about 1m (3feet) tended to get 100's of volts on it. Engineering student came in with dead laptop one day, they'd used a parallel cable to make the data logger a more convenient distance from the laptop's parallel port. Everything was toasted. Memories... \$\endgroup\$
    – Tim Williscroft
    Commented Nov 18, 2010 at 6:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.