Sunday, September 14, 2025

1130 MRAM board - failed chips identified and replaced

LAPTOP CHARGER IMPACT ON ARDUINOS

I have experienced odd behavior with multiple Arduino based items, where plugging my laptop charger into the outlet causes the Arduino and its connected signals to malfunction. The Arduino has to have its ground pins tied to the a ground of a device plugged into the AC mains. Somehow the laptop does a weird change to voltages seen on the Arduino in this case, perhaps it drives voltage onto the ground connections to the other device. 

I did see this again when I was bench testing my MRAM core memory replacement board, using an Arduino Due to produce the address, data and control signals to the board. The bench powers supply delivering 12V to my board would sometimes show zero current flowing, which I suspect was a consequence of power flowing into the regulator device or the bench supply. It also disrupted the behavior of the Arduino program and made the traces on the oscilloscope move up a bit. 

SUSPECTING THE LAPTOP CHARGER ISSUE FRIED ONE OR MORE CHIPS

Much of my board is still working - the internal control signals that drive the MRAM memory chip to read or write, the timers that produce a pulse around 800 ns after the Storage Read or Storage Write input control signals go high, the XOR chain that calculates odd parity, and the NAND output gate that emits a pulse for the two parity bits. What does not appear are any of the 16 data output pulses from NAND output gates. 

I didn't know if the MRAM chip itself had failed, or the NAND output gates for the 16 bits had failed, or the inverting buffers that route the B register inputs to the board onto the memory chip during write had failed. I tacked some wires on pins on the suspect chips so that I could positively identify any malfunctioning parts. 

RESULT OF THE TESTS - WHAT WAS DEFECTIVE

I saw the input bit being driven onto the memory chip data pin during the write, and confirmed that all the control signals were good for the chip to perform a write. I then starting the reading program and saw the memory chip data pin outputting noise when the chip was enabled to output the data that was read. 


The address line for location 1 is the blue trace that I triggered on. The yellow line is the control signal to the memory chip to output the data bits. Green is the sense output line that would pulse downward if the data bit was 1 and purple is the memory data pin itself. The output should go high if there is a 1 in memory at the selected address, but it is low. Within 35 nanoseconds of the Storage Read control signal, the chip should have resolved the contents of the address set up by the address lines (blue), then when the output is enabled (yellow) the result should be output on the data pin (purple). 

I determined from this that the most likely failed part is the MRAM chip itself. Secondarily and much less likely, it could be the NAND gates if they failed so they short their inputs to ground, which I don't believe is the case. 

I saw that some bits were working properly and producing output pulses while others were not. I tacked a wire on another data pin of the MRAM chip and saw similar results - data was gated to the pin during the write process but did not come out during the read process. 

ORDERED REPLACEMENT PARTS FROM DIGIKEY

I placed an order for the MRAM and four of the NAND gate chips which I received this week. I put them on the board and resumed testing. 

3 comments:

  1. Carl, I had some strange side effects with arduino equipment and my notebook charger too. With me I only had garbled USB connections and no fried parts, but I suspect some interference with the arduino ground vs floating notebook ground too. On battery or isolated on my lab PSU everything would work perfectly.

    ReplyDelete
    Replies
    1. You would think that we weren't the only two people to experience this and thus there would be many warnings about this online.

      Delete
    2. Indeed. I also had random problems when trying to write to the serial port of my clone arduinos, but only when using it without the arduino gui. Turns out the GUI sets a lot of options for the port besides the usual XBaud8N1 which will affect reliable communication. This I did not read anywhere too. If you ever have problems trying to access the serial port from your own software, open it with the arduino GUI and copy exactly the options you get displayed when looking at it with stty -F /dev/ttyUSBX -a

      Delete