标签: digital

My aim is to boost your value in only twenty minutes a day. That is the amount of time that commercials take in a one-hour television program. So instead of advancing forward with the DVR or going to the fridge because that food commercial triggered your hunger to go get a snack, here’s the second best thing you can do besides an abdominal workout or throwing dumb bells around. Bettering your engineering skills involves both the physical circuit evaluation and solving equations. As it turns out, you can probably do both for an investment of under $100. In this world of surface mount, highly integrated silicon, expensive software, and sophisticated test equipment, how can that be? Well, relax folks. I’m a power engineer. I’m expected to achieve 100 percent efficiency at no cost. Of course you’ll settle for high efficiency at some cost. However, I’m a cheap skate when it comes to investing in my business. I look for deals that allow you to build a lab at minimal expense. Solving equations is a great way to improve your value. The time spent designing in most engineering jobs is 5 to 10 percent. Or at least that was my experience at larger corporations. That number increased at startups but not much considering I developed web pages, marketing plans, business plans, etc. With such a little amount of time invested, you can quickly lose your skills. This happened to me when I decided to go back to graduate school after three and a half years in industry. In order to refresh my knowledge, I went down to the college bookstore and bought a book titled Schaum's Outline of Electric Circuits. Nowadays you just look it up on Amazon (Reference 2, 3). They are up to the sixth edition versus the 2nd edition I used 25 years ago when dinosaurs ruled the earth and cars consumed fuel at a rate faster than Seattle-ites consume coffee. As for the physical part of improving your value, life is so unfair. Components have shrunk to the point where us fifty-somethings can't even see the darn things. Further frustrating you is the inability to get a scope probe on the lead let alone hook it with the probe. As a final blow, who wants to spend tens of thousands of dollars outfitting a lab? Fear not my friends; El Cheapo to the rescue. The best way to solve the dilemma of the physical circuit is to invest in the old style plugin breadboard with leaded components. I know what you’re thinking: "Good luck finding one and then purchasing the components individually let alone finding leaded ones." I have a solution. It even has jumper wires so you don’t end up stripping that old Ethernet cable that’s long since been replaced by wireless in your home. That will keep you from scrounging around in the attic like an uninvited chipmunk for the second time. Those of you who suffered the fate in the 1990s are probably grimacing in agony at that memory. My solution for a physical lab platform is in the form of the Radio Shack Electronics Learning Lab (Reference 1). Prior to financial strangulation by divorce and cheaper labor, I intended to get one of these for each of my sons. I would wait for Christmas so that the price would drop from $59 to $49. I was pleasantly surprised to find out that these are currently (as of this writing August 2015) going for only $31 smackers.   These make for excellent hobby kits that will have your kids focusing less on thumb pressing their gizmo and more on the physical world and the holidays are just around the corner. No, Radio Shack doesn’t pay me although I could use a break on last minute components for my prototype. I will say that Mouser, Coilcraft, and Fairchild have been more than responsive for providing fast turnarounds. Perhaps you are thinking, "Big deal getting me a thirty dollar circuit that I have to analyze with a kilobucks scope." As it turns out, there are several smartphone applications such as Oscilloscope Pro (See Reference 6) that turn your phone into an oscilloscope. Perform a Google search and you will find both Android and iPhone applications to suit your needs. Just remember, there are voltage limitations to adhere to unless you wish to fry your phone. Don’t be plugging these into the wall until you understand the allowed input ranges. Like oscilloscopes, digital multimeters (DMMs) have really come down in price. Walmart has DMMs (See Reference 8) for under $10. My suggestion is to get one that has the ability to read current as well as voltage. However you might still have to insert a low value resistor in order to read current with an oscilloscope as current probes are not easily adapted to phone based scope applications. I typically parallel ten 1-ohm resistors to ensure accuracy for measuring current. Here is one final hint for you. Although the Radio Shack Learning Lab is battery powered, you just might need to make yourself a DC power source. Instead of hiring me, buying a demo board, or stretching a long lead from the cigarette lighter in your car; grab yourself a bunch of these jacks (490-PJ-002AH , See Reference 7) that fit the plug on most computer power supplies. Although they are surface mount products, you can solder wires to them or order through-hole versions. In addition to smartphone-based oscilloscope applications, you can find some neat little signal generators too. Some versions have PWM capability. Just remember to turn the sound down as the whole office will glare at you like they did me. The one I used would activate the phone’s speaker if I didn’t have a load plugged into the audio jack. Don’t tell your offspring that these signal generator apps are available as they need to experience the frustration of wiring a 555 timer for themselves. It probably won’t work anyway as they have most likely already downloaded the sig gen app between times when they were getting game cheat codes and overusing the world “like”. By the way, I developed an app that counts that overuse for you!   Scott Deuty

My first job fresh from college was testing and debugging control loading systems on flight simulators for 747 and the "new" 767 airliners. In the late 1970s, the control loop that simulated the feel of the primary flight surfaces, and had to respond instantaneously to pilot inputs, was purely analogue; the digital portion consisted of a 32-bit Gould SEL "super minicomputer" with schottky TTL and a screamingly-fast 6.67 MHz system clock; it merely provided voltage inputs via DACs into an op amp summing junction which represented slowly-changing parameters such as airspeed and pitch angle.   "Op Amp", of course, is short for "Operational Amplifier", first developed to perform mathematical operations in analogue computing. Forget about FFTs, DSPs, and all that nonsense: back in the mid-70s (when analogue giants walked the earth and the Intel 4004 was barely out of diapers) there was an analogue IC for just about everything – multiplication and division, log and antilog operations, RMS-DC conversion, you name it.   With the later rise of the Dark Side , of course, many of those old analogue components, as well as the companies that gave them life, have breathed their last.   At least some of those functions survive, either as standalone parts or (sigh) as microcontroller functional blocks. And the real world, thankfully, remains stubbornly analogue, which means that most of the truly interesting "digital" problems are really analogue problems – grounding, crosstalk, race conditions, noise, EMC, etc.   We humans are products of the real world, too. Are we analogue or digital?   The information that makes up a unique human being is mostly to be found in two places, in our genes and in our brains. The information in genes can be considered digital, coded in the four-level alphabet of DNA. Although the human brain is often referred to as an analogue computer, and is often modeled by analogue integrated circuits, the reality is more nuanced. In a fascinating discussion on this subject, computational neuroscientist Paul King states that information in the brain is represented in terms of statistical approximations and estimations rather than exact values. The brain is also non-deterministic and cannot replay instruction sequences with error-free precision; those are analogue features.   Figure 1 Figure 1: Analog, digital, and neuron spiking signals (source: Quora )   On the other hand, the signals sent around the brain are "either-or" states that are similar to binary. A neuron fires or it does not, so in that sense, the brain is computing using binary signals.   The precise mechanism of memory formation and retention, though, remains a mystery and may also have both analogue and digital components.   Is life itself analogue or digital? Freeman Dyson, the world-renowned mathematical physicist who helped found quantum electrodynamics, writes about a long-running discussion with two colleagues as to whether life could survive for ever in a cold expanding universe . Their consensus is that life cannot survive forever if life is digital, but life may survive for ever if it's analog.   What of my original topic - analogue vs digital computation? In a book published in 1989, Marian Pour-El and Ian Richards, two mathematicians at the University of Minnesota, proved in a mathematically precise way that analogue computers are more powerful than digital computers. They give examples of numbers that are proved to be non-computable with digital computers but are computable with a simple kind of analogue computer.   Consider a classical electromagnetic field obeying Maxwell's equations: Pour-El and Richards show that the field can be focused on a point in such a way that the strength of the field at that point is not computable by any digital computer, but it can be measured by a simple analogue device.   The book is available for free download . Digital engineers, knock yourself out.   Meanwhile, analogue rules supreme. Which, of course, we analog engineers knew all along.   Now, about that raise.....   Paul Pickering

A provocative analyst prediction can really get people talking. Several years ago, it was Gartner's prediction that marketing organizations will outspend IT organizations on technology by 2017. Not to be outdone, the provocateurs at IDC last week weighed in with their own headline-grabber: By 2020, chief digital officers (CDOs) will "supplant" 60% of CIOs at global companies "for the delivery of IT-enabled products and digital services."   In other words, most CIOs -- if the position still exists at their companies in five years -- will be relegated mostly to managing and securing infrastructure and applications, according to the IDC prediction, one of 10 that the research firm laid out as 2014 comes to a close. CDOs, meantime, will take on the more strategic (and fun) role of applying digital technologies -- mobile, cloud, analytics, social, robotics -- to boost revenue, maximize profits, and delight customers. CIOs = back office. CDOs = front office. It's 1989 all over again.   Here's my prediction: By 2020, chief digital officers will be yesterday's fad, joining the ranks of chief innovation, learning, and culture officers. Sure, a handful of them will still exist, but the CIO -- customer-focused and product-savvy -- will drive the corporate digital agenda in partnership with CEOs, CMOs, CFOs, and other business leaders. CIOs won't go back to being order-takers. "What good CIO would let that happen?" says Cathy Bessant, head of Bank of America's 100,000-person Global Technology and Operations unit, which includes six or seven CIOs.   Those CIOs who can't cut it as digital innovators and customer pleasers will go the way of CFOs who can't think outside of their spreadsheets and CMOs who can't move beyond direct-mail marketing and banner ads. That is, they'll lose their jobs because of their failure to keep up with the times and corporate priorities.   But that doesn't mean roughly 60% of current technology chiefs aren't up to the challenge of leading the next great technology movement. You can already size up the CIO of tomorrow by looking at the top CIOs of today -- the likes of Rob Carter at FedEx, Lynden Tennison at Union Pacific, John Halamka at Beth Israel Deaconess Medical Center, Karenann Terrell at Wal-Mart, and Gordon Wishon at Arizona State University -- all technically astute, customer-focused, business savvy. They're not MIS chiefs; they're strategists.   Getting to that level isn't a bridge too far even for CIOs who today may be spending too much of their time in the weeds. In a recent Gartner survey of more than 2,800 CIOs in 84 countries, 73% of respondents said they have changed their leadership style over the last three years, and 75% said they need to change their style over the next three years, to meet the demands of digital business. "The exciting news for CIOs," Gartner maintains, "is that despite the rise of roles such as the chief digital officer, they are not doomed to be an observer of the digital revolution."   Not only do most marketing-bred CDOs lack the technical expertise to lead the digital charge, but they also lack the project management experience, says Satya Ramaswamy, head of the Digital Enterprise unit of Tata Consultancy Services. "We are not seeing CIOs going away at all," Ramaswamy says. Especially at large scale, "digital reimagination," as he calls it, "is too complex for someone with a marketing background. There's so much going on the back end to drive the front." The two aren't separable.   Despite its optimism about the future role of the CIO, Gartner issued a warning: "Through both nature and nurture, CIOs have evolved into control-style pragmatic leaders," Gartner VP Graham Waller said in a statement. "Given the characteristics of the new digital era, this bias is dangerous. CIOs must invert their style to be more vision-led and inspirational."   Bank of America's Bessant, a former company CMO in her own right, says CIOs do need to adopt the mindset of "thinking digital first, digital by design."   "I can see the cultural revolution that we've got to have," she says. "But good/great technologists are awesome problem-solvers and have the ability to see the future. Shame on any CIO who can't see that coming."   If the world wasn't changing, we might continue to view IT purely as a service organization, and ITSM might be the most important focus for IT leaders. But it's not, it isn't and it won't be -- at least not in its present form.   Rob Preston currently serves as VP and editor in chief of InformationWeek, where he oversees the editorial content and direction of its various website, digital magazine, Webcast, live and virtual event, and other products. Rob has 25 years of experience in high-tech

An analogue engineer and a digital engineer collaborate, use their respective skills, and pull a few bunnies out of a hat to troubleshoot a system with which they are completely unfamiliar. Our sales department had just accepted a new challenge on behalf of Engineering. They promised a customer that yes, of course, we can repair a telecom product that we have never seen before and for which we have no systems, no test fixtures, and no schematics. (The OEM no longer supported this product.)   Engineering was once again expected to shake our rattles, do our magic voodoo dance, and pull bunnies out of hats. About fifteen of these backplane-pluggable boards showed up in my office for initial evaluation and perusal of their inner workings. They had a proprietary SIMM (socketed memory module), which on several units turned out to be bad. Temporarily substituting the memory modules from other cards with obvious smoke damage failure modes brought them back to life when powered while lying flat on the bench. (Remember, there was no test chassis available.) They would then boot and talk to us over their RS232 ports.   These modules were populated with four SRAMs and four flash memories, each flash and SRAM shared an 8-bit-wide data bus, and each pair of SRAMs was enabled together with the same chip select. I proposed to the boss that we build a small test fixture that would take the DUT memory module, run SRAM tests, and if necessary reprogram the flash.   A digital/software colleague three cubes away was assigned to work with me on this project. He had previously designed and laid out a PCB that used a surface-mount PIC microcontroller as a universal I/O for our current and future test fixtures. It turned out that it had just enough I/O lines to handle the address and data buses on the DUT memory module, with two spares, as long as I tied the four separate DUT data busses together into two pairs on the fixture. So we decided to use it.   I ordered the necessary SIMM connector and a plated-through-hole protoboard, along with some ribbon cable and IDC header sockets to connect to the PIC board. It was somewhat annoying that the 72-pin SIMM connector was spaced at a.05-inch pitch, so the protoboard also had to be this pitch. Its tiny .025-inch-diameter holes did not accept .025-inch-square pins, so wire-wrap was impossible. (Now I know where that old adage, "Can't fit a square peg into a round hole," came from.)   I had to solder ribbon cable directly to the protoboard and string short 30AWG wires to the SIMM connector. As long as the stranded ribbon wires were not overly tinned (to keep the strands together), they actually fit into the protoboard holes.   Endeavor brings back cuss words long since forgotten Another annoyance was that the SIMM connector had plastic retaining tabs that quickly wore out from repeated insertions of memory modules. The maker had designed them for maybe a single SIMM replacement over the lifetime of the product. We wanted to plug DUTs in and out constantly.   Fortunately I had used socket pin strips in the protoboard for the SIMM connector in anticipation of eventually needing to replace it easily. I subsequently found a connector with metal retaining tabs. This particular feature does not show up in vendors’ online part descriptions. I had to look at the mechanical drawing of each of many to find "W/ Metal Latch."   The first test of the fixture went well. My colleague coded a walking-ones SRAM test that immediately identified bad SRAM chips on a couple of the DUT (Device Under Test) boards. We replaced them and now they booted, but with the disconcerting message "RAM is BAD." Due to availability we had used 12 nsec SRAMs in place of the original 20 nsec SRAMs, so speed was probably not the issue. Hmmm, maybe we needed to improve the test algorithm.   Then we got brave and copied about five different versions of firmware from the flash of the good memory modules and tried to re-write the new firmware into a module, which semi-booted at first but complained about a "missing application loader." After the firmware re-load it would no longer even talk to us over its RS232 port. Somehow a 'known good' firmware load messed it up. My colleague verified that the firmware in the good and bad modules was identical. So why did one boot and not the other? Speed?   My colleague continued writing his code and progressed to a walking-zeros test. Strange things began to happen. On several known good memory modules two SRAMs with their data busses tied together consistently failed in the same way: When 7F was written, FF got read back. It only failed on one pair of SRAMs. The other SRAM pair always worked properly.   Had I connected a wire wrong on the fixture? We put a scope on the fixture and verified that yes, when he wrote 7F that is what came back from the DUT SRAM and the fixture. Clearly his PIC microcontroller was reading a definite logic 0 as a logic 1, but only on bit 7 of that data bus. Yet the walking one's test had worked and bit 7 was correctly read as a logic 0 during that test.   Since I was not familiar with his PCB layout or the PIC chip, I asked him to send me his KiCAD board layout file. I already knew there were no power/ground planes, but I had not expected to see that some of his ground pin connections snaked in and out in roundabout paths when they should have all been joined together under the PIC chip.   Some of his Vdd connections were not even connected to the Vdd copper, but instead depended on connections within the chip. His decoupling capacitor was an inch away, adding two inches of trace inductance. I smelled analogue problems here, possibly due to the power routing. One way to find out if a suspect actually is the cause of a problem is to eliminate it. I used an approach that had been successful before, which was to add power planes and more decoupling. Here is a photo of the end result, done by one of our highly-skilled production soldering experts:   Two squares of single-sided copper-clad form the mini-power planes. Decoupling 0805 chip capacitors standing on their ends are just the right size to AC-couple the planes together. (Somehow this sounds like an oxymoron). The PIC cannot complain about poor power etch routing. All its power and ground pins are now tied together.   Unfortunately this did not help. But it did eliminate the power suspect. I still smelled an analogue problem.   This was further confirmed when we ran some tests to see if any other byte patterns caused bit 7 to falsely read a one when it was really a zero. Turned out there were many patterns that did this. If as few as three lower-order bits were ones, the PIC would read bit 7 as a one when it was really a zero. It didn't seem to matter which lower order bits, all it took was three or more set to one. With enough of them HI they seemed to bleed into bit 7. Was it analogue voltage summation?   Then it hit me. My colleague's PIC was running at 3.3V. My memory module DUT was powered at 5Vs. My colleague had previously assured me that his PIC inputs were 5 volt tolerant -- the data sheet said so. I took a closer look at the data sheet. On the first page it did say "5.5V Tolerant Inputs (digital-only pins)." So if the inputs are configured as digital, they should be 5V tolerant, right?   Some 146 pages into the data sheet was a bit (no pun intended) more detail: Any inputs that could be configured as either analogue or digital are NOT 5V tolerant. They have clamp diodes to 3.3V Vdd. All eight bits of the problem data bus and one bit of the other data bus went to such inputs. Yes, it was an analogue problem -- the 5V ones were overdriving the inputs and adding voltage-wise. I invented a couple of new cuss words.   This explained the problem with the one flash we had overwritten that would no longer boot. All the firmware images we had copied previously were garbage. I had to heat up the soldering iron again, hack into the test fixture, and carefully cut ribbon cables to add a couple of 74LVC245 bus transceivers with 5V tolerant inputs. My knowledge of PIC microcontrollers and my expletive vocabulary both improved considerably.   But it solved the problem and we could now identify bad SRAM devices and re-write the bad flash. The "RAM is BAD" message turned into "RAM is OK" after a flash re-write. Possibly the flash had logged the previous SRAM failures.   Success was achieved by a pair of engineers, one digital and one analogue, each with his own skill set, working together to solve the problem.   Glen Chenier Engineer

An analogue engineer teams up with a digital engineer, they use their respective skills, and pull a few bunnies out of a hat to troubleshoot a system with which they are completely unfamiliar. Our sales department had just accepted a new challenge on behalf of Engineering. They promised a customer that yes, of course, we can repair a telecom product that we have never seen before and for which we have no systems, no test fixtures, and no schematics. (The OEM no longer supported this product.)   Engineering was once again expected to shake our rattles, do our magic voodoo dance, and pull bunnies out of hats. About fifteen of these backplane-pluggable boards showed up in my office for initial evaluation and perusal of their inner workings. They had a proprietary SIMM (socketed memory module), which on several units turned out to be bad. Temporarily substituting the memory modules from other cards with obvious smoke damage failure modes brought them back to life when powered while lying flat on the bench. (Remember, there was no test chassis available.) They would then boot and talk to us over their RS232 ports.   These modules were populated with four SRAMs and four flash memories, each flash and SRAM shared an 8-bit-wide data bus, and each pair of SRAMs was enabled together with the same chip select. I proposed to the boss that we build a small test fixture that would take the DUT memory module, run SRAM tests, and if necessary reprogram the flash.   A digital/software colleague three cubes away was assigned to work with me on this project. He had previously designed and laid out a PCB that used a surface-mount PIC microcontroller as a universal I/O for our current and future test fixtures. It turned out that it had just enough I/O lines to handle the address and data buses on the DUT memory module, with two spares, as long as I tied the four separate DUT data busses together into two pairs on the fixture. So we decided to use it.   I ordered the necessary SIMM connector and a plated-through-hole protoboard, along with some ribbon cable and IDC header sockets to connect to the PIC board. It was somewhat annoying that the 72-pin SIMM connector was spaced at a.05-inch pitch, so the protoboard also had to be this pitch. Its tiny .025-inch-diameter holes did not accept .025-inch-square pins, so wire-wrap was impossible. (Now I know where that old adage, "Can't fit a square peg into a round hole," came from.)   I had to solder ribbon cable directly to the protoboard and string short 30AWG wires to the SIMM connector. As long as the stranded ribbon wires were not overly tinned (to keep the strands together), they actually fit into the protoboard holes.   Endeavor brings back cuss words long since forgotten Another annoyance was that the SIMM connector had plastic retaining tabs that quickly wore out from repeated insertions of memory modules. The maker had designed them for maybe a single SIMM replacement over the lifetime of the product. We wanted to plug DUTs in and out constantly.   Fortunately I had used socket pin strips in the protoboard for the SIMM connector in anticipation of eventually needing to replace it easily. I subsequently found a connector with metal retaining tabs. This particular feature does not show up in vendors’ online part descriptions. I had to look at the mechanical drawing of each of many to find "W/ Metal Latch."   The first test of the fixture went well. My colleague coded a walking-ones SRAM test that immediately identified bad SRAM chips on a couple of the DUT (Device Under Test) boards. We replaced them and now they booted, but with the disconcerting message "RAM is BAD." Due to availability we had used 12 nsec SRAMs in place of the original 20 nsec SRAMs, so speed was probably not the issue. Hmmm, maybe we needed to improve the test algorithm.   Then we got brave and copied about five different versions of firmware from the flash of the good memory modules and tried to re-write the new firmware into a module, which semi-booted at first but complained about a "missing application loader." After the firmware re-load it would no longer even talk to us over its RS232 port. Somehow a 'known good' firmware load messed it up. My colleague verified that the firmware in the good and bad modules was identical. So why did one boot and not the other? Speed?   My colleague continued writing his code and progressed to a walking-zeros test. Strange things began to happen. On several known good memory modules two SRAMs with their data busses tied together consistently failed in the same way: When 7F was written, FF got read back. It only failed on one pair of SRAMs. The other SRAM pair always worked properly.   Had I connected a wire wrong on the fixture? We put a scope on the fixture and verified that yes, when he wrote 7F that is what came back from the DUT SRAM and the fixture. Clearly his PIC microcontroller was reading a definite logic 0 as a logic 1, but only on bit 7 of that data bus. Yet the walking one's test had worked and bit 7 was correctly read as a logic 0 during that test.   Since I was not familiar with his PCB layout or the PIC chip, I asked him to send me his KiCAD board layout file. I already knew there were no power/ground planes, but I had not expected to see that some of his ground pin connections snaked in and out in roundabout paths when they should have all been joined together under the PIC chip.   Some of his Vdd connections were not even connected to the Vdd copper, but instead depended on connections within the chip. His decoupling capacitor was an inch away, adding two inches of trace inductance. I smelled analogue problems here, possibly due to the power routing. One way to find out if a suspect actually is the cause of a problem is to eliminate it. I used an approach that had been successful before, which was to add power planes and more decoupling. Here is a photo of the end result, done by one of our highly-skilled production soldering experts:   Two squares of single-sided copper-clad form the mini-power planes. Decoupling 0805 chip capacitors standing on their ends are just the right size to AC-couple the planes together. (Somehow this sounds like an oxymoron). The PIC cannot complain about poor power etch routing. All its power and ground pins are now tied together.   Unfortunately this did not help. But it did eliminate the power suspect. I still smelled an analogue problem.   This was further confirmed when we ran some tests to see if any other byte patterns caused bit 7 to falsely read a one when it was really a zero. Turned out there were many patterns that did this. If as few as three lower-order bits were ones, the PIC would read bit 7 as a one when it was really a zero. It didn't seem to matter which lower order bits, all it took was three or more set to one. With enough of them HI they seemed to bleed into bit 7. Was it analogue voltage summation?   Then it hit me. My colleague's PIC was running at 3.3V. My memory module DUT was powered at 5Vs. My colleague had previously assured me that his PIC inputs were 5 volt tolerant -- the data sheet said so. I took a closer look at the data sheet. On the first page it did say "5.5V Tolerant Inputs (digital-only pins)." So if the inputs are configured as digital, they should be 5V tolerant, right?   Some 146 pages into the data sheet was a bit (no pun intended) more detail: Any inputs that could be configured as either analogue or digital are NOT 5V tolerant. They have clamp diodes to 3.3V Vdd. All eight bits of the problem data bus and one bit of the other data bus went to such inputs. Yes, it was an analogue problem -- the 5V ones were overdriving the inputs and adding voltage-wise. I invented a couple of new cuss words.   This explained the problem with the one flash we had overwritten that would no longer boot. All the firmware images we had copied previously were garbage. I had to heat up the soldering iron again, hack into the test fixture, and carefully cut ribbon cables to add a couple of 74LVC245 bus transceivers with 5V tolerant inputs. My knowledge of PIC microcontrollers and my expletive vocabulary both improved considerably.   But it solved the problem and we could now identify bad SRAM devices and re-write the bad flash. The "RAM is BAD" message turned into "RAM is OK" after a flash re-write. Possibly the flash had logged the previous SRAM failures.   Success was achieved by a pair of engineers, one digital and one analogue, each with his own skill set, working together to solve the problem.   Glen Chenier Engineer