93LC66B DO should be HiZ and do nothing to the bus when it is not actively sending data or erase/write status. If it “fails” you should get all 0xff when reading because of the pull-up
Something is holding DO low even though the chip hasn’t been enabled
If you are sure of the connections, then is this chip in a board where something else is pulling the output to 0?
That can be tricky. You’ll need to determine what else is on that SPI bus and how to disable it. It could be a big pull-down, but that would be unusual and defeat the point of the ACK bit this chip gives.
Is the board running, or are you trying to power the chip from the Bus Pirate?
Are you certain of the voltage supply if you are powering from the BP?
Is there some kind of security to avoid reading out the EEPROM?
I tried voltage 3V3 and 5V. Board is not powered. Using VCC from BusPirate. The board is 6V tolerant so it should be fine to use either 3.3 or 5V. I will try with the hooks provided with BusPirate now. Cuz I don’t trust this Pomona clip even its original.
You should probably measure the board’s voltage while running and then match that.
It’s also possible the Bus Pirate is powering the rest of the board and other chips are booting as well. Possibly partially as the Bus Pirate might not be able to handle the load.
How much current is being used?
This is from a UPC? Are you certain the board is 6V tolerant, and not just the max rated power supply? The chip is only rated to 5.5volts, so it would be out of spec at 6volts.
I made measures and it seems like its SOIC not rotated SOIC. VCC on the right side and NC and VSS is tied to GND and ORG is NC. At 3V3 from BP5 the current is around 50-60mA floating a bit. So if it would power stuff around I would expect it to be more.
Are the numbers you’re seeing consistent with the logic analyzer output?
It’s very challenging to read a chip in circuit. You need to identify the master chip and figure out how to hold it in reset. That you’re seeing all 0x00 instead of 0xff shows that there is definitely something else active on the bus.
So on the BP5 we can only see the signals the Bus Pirate is generating, we can’t see what is actually happening on the bus. BP6 has an extra buffer to address this situation.
It is completely possible that the bus is active and we just don’t see the contention.
The fastest thing you can do is use PulseView in normal mode, set a trigger on CS pin, and see if there is any activity that trigger the capture.
You could also use a decent scope to watch the pins one by one.
Something is holding the pull-up resistor to ground, until that issue is addressed you won’t be able to read the chip. It is possible that bricked MCU is bricked in a way that DO is stuck at ground. It could be a million things, especially on a board that isn’t working properly.
Figured it out. According to the guide I was following to unbrick it before. There is SWIO/JTAG connector with RST pin. I just grounded it. And now the current is steady ~17mA and I get consistent dumps.
First bit is zero tho. Was it over-written? Or is it a coincidence. Anyway happy with the result. And also 3-Wire mode seems to work fine after some fiddling. Here is the begining of my EEPROM:
Highly doubt it. You would need to unlock the latch first, then successfully run the erase command. Plus the chip wasn’t reading so I doubt it would work. Also, the logic graph doesn’t show it responding to anything.
Likley it’s a 4 byte version number or some kind of header.
Ok following up is there some way to save it as binary on the buspirate storage for further bisecting? Or do I have to copy-paste that into some hex editor. Also should check ASCII output to check if its meaningfull if not then MSB/LSB change I guess.
Dumping is a common use case and I’ve had an idea how to deal with it.
How about this: a global command:
You set up the read manually
The command uses the current mode read function to read x bytes and save them to a file
Most every memory has some kind of sequential read command (except maybe 1 wire). But the way to set up the read is different. So you get it to the right state, and the command dumps X bytes to a .Bin file.
Yes, absolutely. I’ve thought about that, but it would be pretty ugly to implement inside the syntax compiler as it currently works. It would also not benefit from having a help menu explaining how it works.
A dump command I can push tomorrow morning. Modifications to syntax compiler would take a few days of messing around.