Issues flashing 1.8V ROM chip with BeagleBone Black via SPI

[grungus]

Hi I am trying to figure out how to flash a 1.8V rom chip, MX25U12835F, in SOP-8 package using BeagleBone Black. I have spidev0 loaded, with the .dtbo enabled in uEnv.txt, and flashrom installed. Kernel is 6.16.x.

The BBB’s spi0 pins are hooked up to an Adafruit TXB0108 on a breadboard which has a 3.3V ref voltage on the high side and a 1.8V ref on the low side. The low side equivalent pins are hooked up to a Pomona SOIC clip which is on my ROM chip in situ on the motherboard. The 3.3V is coming from a breadboard power adapter and the 1.8V is coming from that same adapter’s 5V output ran through an LM317 breakout. The chip is powered with the 1.8V line on my breadboard and the grounds of each component are connected. I read that BBB is 3.3V output so it wouldn’t be suitable for a 1.8V chip and I’d risk frying it trying to use it without the TXB, which is how I ended up here.

My problem is that when I have everything hooked up and the clip on my SOP chip, flashrom doesn’t detect anything. The Write Protect and Reset pins on my clip aren’t hooked up to anything because I couldn’t find much info on them I could make sense of aside from a gnu.org guide that told me not to hook them up.

I am completely new to the electronics side of this so I don’t know where I’m going wrong. Any help would be appreciated.

[lranders]

Ahh, the classic “lets run before we can crawl scenario”…

Why don’t we dispense with all the fancy setup and just start by connecting
the MOSI to MISO and then run the spidev_test utility to see if everything
is set up as expected?

The test utility is found on kernel.org.

Ideally, you would want to hook up a scope or at least some kind
of logic analyzer so you don’t have to drive blind.

[amf99]

@grungus

MX25U12835F

have you loaded the macronix driver ?

[grungus]

Haha you’re completely right, I’m in way too deep for a beginner! Although I did look a fair bit for documentation or tutorials on setting up BBB’s SPI for flashing ROM chips but couldn’t find anything thorough and up-to-date with more recent kernels and revisions.

Seems like there was a set-up tutorial at https://www.gnu.org/software/gnuboot/docs/install/bbb_setup.html but it got removed and I couldn’t find any archives or back-ups of it.

Regardless, thanks for the prompt response, it’ll be good to get this sorted out. I ran spidev_test -v and this was the output.

spi mode: 0x0
bits per word: 8
max speed: 500000 Hz (500 KHz)
TX | FF FF FF FF FF FF 40 00 00 00 00 95 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF F0 0D  | ......@....•..................ð.
RX | FF FF FF FF FF FF 40 00 00 00 00 95 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF F0 0D  | ......@....•..................ð.

Unfortunately I don’t have a scope or logic analyzer, just a multimeter. I did notice my TXB0108’s MOSI and SCLK pins were always at 1.8V on the low-voltage side even when the high-voltage side’s were only 0.72V and 0.16V respectively but I don’t know if it’s supposed to do that.

[lranders]

Well, at least you know how to properly format your posts, so as far as you calling yourself
a beginner, you’re already ahead of so many others in this place!

It’s a good first step to verify that your spidev actually works as expected.
Is that capture taken with MOSI connected to MISO right on the BBB pins,
or did you try and loop 'em through the TXB and back?

If I remember correctly, it’s possible for spidev_test to send a crafted message as well,
so why not try to see if you can send and receive the device status word?

You wouldn’t happen to have a flash rom device you can connect on the 3.3V side?

As @amf99 suggests, you could also consider looking at having Linux talk
directly to the device, but I think it’s important to establish and verify the physical
interface before you start with that; refer to previous metaphor.

Once we have the physical layer straightened out, we can look at recompiling the
device-tree overlay and let the kernel know about the MX25…

One firm piece of advice though: Go get a cheap logic analyzer; you’ll be happy you did…

I wouldn’t be surprised if someone already made one using a Raspberry Pi Pico,
so they don’t have to cost an arm and a leg like they used to.

[lranders]

One quick question though:

What side of the TXB did you connect to the BBB and what side for the MX?

If I understand it correctly, the BBB should be on the B side of the translator…

[amf99]

as for a cheep logic analyzer, sipeed slogic combo 8, picked this up off of amazzzzz for like 20 bucks.

[lranders]

Yea, as I said, you don’t need a $200.000 Tektronix…

[grungus]

That capture was just with the MOSI and MISO pins linked directly to each other. I can try to loop them through the TXB if it would be safe to do so.

I will get the logic analyzer as soon as I can, sounds like it would be a good way to verify that the finicky electronic parts of this process are working correctly.

I don’t have a dedicated flashing device I could hook up to the 3.3V side yet, but I have ordered a CH341A which should be on the way next week.

I don’t know what the device status word is or how to get it, so I just did “hello world” instead with spidev_test -p on the loopback. This was the result:

spi mode: 0x0
bits per word: 8
max speed: 500000 Hz (500 KHz)
TX | 68 65 6C 6C 6F 20 77 6F 72 6C 64 __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __  | hello.world
RX | 68 65 6C 6C 6F 20 77 6F 72 6C 64 __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __  | hello.world

Some good news, I ended up finding an old netbook that hadn’t been used up in years which had a 3.3V flash chip, the GD25Q16(B). I hooked it up straight to my BBB and managed to perform a successful read and dump using flashrom, so it seems the issue isn’t likely to be on the BBB’s end at least.

@lranders

What side of the TXB did you connect to the BBB and what side for the MX?

I had the BBB on the B side and the MX25U on the A side.

[lranders]

Outstanding!

If you have a variable voltage supply, you could put the known-good GD25Q16
on the A side, set V_CCA to 2.7V and try flashrom again.

That’ll give us a clue to what’s going on, but I got the sneaking feeling we’re close.

[lranders]

Actually, a short search on Google reveals several posts about issues
with the TXB line of devices and SPI in general.

The TXS sounds to be better suited to your application…

[grungus]

I did see on the Adafruit page for the TXB breakout that it isn’t suitable for I2C or longer range than than a breadboard in general, but I wasn’t knowledgeable enough at the time to figure it’d apply to SPI too; my cables are only a few inches so I thought it’d be fine. I just saw someone recommend it on r/AskElectronics for this purpose and went in blind .

Like you said, “run before we can crawl”… At least I learned a lot in the process of getting things wrong!

I did see in this thread on r/embedded that I may be able to pull off SPI communication with a 1.8V chip using a simple voltage divider circuit, although this thread on r/raspberry_pi indicates otherwise. I do have the LM317 to regulate power supply but the I/O is a lot more complicated from what I’m gathering. Even if a divider were to work, I don’t know whether the BBB’s MISO would accept a 1.8V input or if I would have to boost it somehow.

Anyway, I’ll leave that for later and focus on hooking the GD25Q16 up to the TXB’s A-side, once I get home, and report back with the results!

[lranders]

Failure is a great teacher ..

[lranders]

You could also consider dispensing with those flaky auto-sensing auto-directionals
and just use two 74LVC1G125’s, one in each direction.

The 74LVC1G97 looks really nifty as well; never saw that variant before…

[grungus]

Okay so I got around to doing the final tests, and it seems like the problem lies with the TXB. This is a long post, but I wanted to be thorough and try a few extra setups just to make sure the TXB is the problem.

Just so I don’t state it with each example, the BBB was always on the B-side providing the 3.3V ref voltage for the TXB. V_CC and common ground were established via the mini-breadboard’s power rails. WP# and HOLD# pins weren’t be connected. The Samsung NC110 mainboard has LEDs that indicate operation of individual components such as the GD25Q16, so I’ll be using that as an indicator of successful connection. The mainboard was removed from the case and all attached components etc. were removed, except for the CPU.

With the LM317 set to 2.7V hooked up to the TXB’s V_CCA, flashrom’s probe did not detect the chip at all. The LED would flicker on then remain off when I attached the SOIC clip to the chip. It wasn’t a pin contact issue as I tried re-attaching the clip multiple times, while my attempts without the TXB worked first try each time. I don’t know if this indicates a current issue or something else; I tested the V_CCA at various points in the circuit with my multimeter and it was always 2.7V. I tried 128 and 512kHz with the TXB.

With the LM317 output set to 2.8V, hooked up to the GD25Q16’s V_CC, and the BBB hooked up to the I/O pins, I could perform a successful probe and read. LED stayed on throughout. The difference in operating voltage didn’t seem to matter.

With my PSU’s 3.3V output hooked to up the GD25Q16’s V_CC, and the BBB hooked up to the I/O pins, I could perform a successful probe and read. LED stayed on throughout.

With the GD25Q16 hooked up directly to the BBB, I could perform a successful probe and read. LED stayed on throughout.

So I guess that’s it. The TXB0108 isn’t suited for SPI applications outside of a breadboard or similar short-range setup, most likely due to output drive, the auto-direction feature malfunctioning, or some other issue. I have a CH341A on the way which comes with a 1.8V adapter, so hopefully that will get the job done. The adapter might even work with the BBB if I’m lucky. If not, I’ll look into getting two 74LVCs or a TXS0108E. I’ll get that logic analyzer too.

Regarding the directional aspect of MOSI and MISO channels with uni-directional translators like the 74LVC: there’s a lot of conflicting info online, but since each SPI channel is uni-directional which facilitates bi-directional communication, I might be able to get away with a single 74LVC if I hook up the ROM chip’s MISO directly to my BBB and run everything else through a 74LVC (provided the BBB’s MISO will accept a 1.8V signal). A simple voltage divider might work with a low enough clock speed in a pinch but may not be good for data integrity. Threads I gathered this info from: One and two.

Thanks both of you for all the help! I learned a lot throughout this process and feel a lot more capable working with the BBB’s SPI and with ROM chips in general. Hopefully anyone else looking to learn more about these topics can use this thread to guide them. I’ll mark this as solved but may provide updates in the future.

[lranders]

@grungus

Regarding the directional aspect of MOSI and MISO channels with uni-directional translators like the 74LVC: there’s a lot of conflicting info online, but since each SPI channel is uni-directional which facilitates bi-directional communication, I might be able to get away with a single 74LVC if I hook up the ROM chip’s MISO directly to my BBB and run everything else through a 74LVC (provided the BBB’s MISO will accept a 1.8V signal). A simple voltage divider might work with a low enough clock speed in a pinch but may not be good for data integrity. Threads I gathered this info from: One and two.

Yea, the reason I suggested the 1G family was because if you connect the OE of those 125’s to SPI_CS, and their V_CC's to their respective sides, you won’t have to bother with voltage dividers or any other fiddly stuff.

While it is true that the AM33 SPI pins can be bi-directional, once you program them via the correct Device tree overlay, they will behave as unidirectional pins. Coupled with the OE tip from above, you won’t ever get yourself into trouble. You might need some bias resistors for when the 1G outputs go into Hi-Z, but further testing will have to confirm this.