How to read address x all the way to address y in I2C ?

[MathWizard]

I'm looking at a 24C04 eeprom w/ Buspirate, and I found what is the EDID data, starting at byte 13. And I'm just trying to understand the syntax, and if this is even possible.

In the terminal/bash thing Putty, w/buspirate
In the eeprom, I want to read starting at byte13, and also read the next 128 bytes

I wired the chip as 0xA0/1
if I type
[0xA1 r:141]
it will read and list the values up to the 141st byte. In this manual I don't understand the bulk reads, and the ... they use, on page 8 maybe not the best guide, but searching this stuff up is like catching air in a net.
http://www.buspirate.com/tutorial/bus-pirate-command-guide?format=pdf

r Read byte
I2C>r
READ: 0x00
I2C>r:3
READ: ACK 0x00 ACK 0x00 ACK 0x00
I2C>
r reads a byte from the bus. Use with the repeat command (r:1...255) for bulk reads

I tried just putting a space in , like r:13 141 , and the ..., and that's not the way either

Any tips ? thanks

I just want the relevant bytes on screen thats all.  Is there some pointer thing too, where it tells the chip to poind at an address, and then maybe tell it to read the next desired number of bytes in a row ?


maybe thats still not how that read command works, now, after unplugging it/replugging it, and typing
[0xA1 r:141]
I did not see the EDID code, but I did find it before, I could see the Fixed header pattern, and the EDID version bytes

[DavidAlfa]

Check the datasheet, it's not just i2c, it's the EEPROM protocol running on top of it.
"r" reads 1 byte, add ”:n" to make a bulk read of n bytes.
"1...255" means any number between 1 and 255!

To read a random address, you must first write the address (13 in your case), send another start(restart), and read the bytes.


Something like this. Note the restart condition.

[0xA0 13[0xA1 r:128]

Not sure, never used buspirate, but that's what it seems.

[MathWizard]

[ Specified attachment is not available ]Ok I wasn't adding the extra start condition, yeah I still get a bit confused by the datasheets. But I do remember the start/stop conditions electrically.

The chip only has 2x256x8 bits as well, I was thinking it's 4k bytes.

I'm so used to using windows, or even DOS as a kid, I think this stuff has way more user-interface built in then it does.

I should try this stuff with Arduino, that's way more documented and user friendly. IDK how real hackers program the BP in the same way, to do useful stuff, like save the results of a read.

Here's a snap tho, the highlight part is the start of the EDID, ignoring the ack's, and the missing stop

[DavidAlfa]

I guess you already did before runing that cmd, but justr in case, keep in mind the address counter increases on every read and it doesn't reset when starting a new read.
So better to write the address first. Otherwise your reading will start at whatever the address was set at.

Ex. read 128bytes starting from address 0:
[0xA0 0[0xA1 r:128]

[MathWizard]

Ok thanks, I'm getting the hang of it a bit more each time. This should be the whole 4k


There's another 16k eeprom w/ 8x256 bytes, on another monitor I'm looking at, it's hooked to the monitor's purpose built MCU, it's GPIO's. It reads as all blank, that seems weird, here's some of it, if I'm doing it right. I' m not tho, it's giving a NACK after the write's, the other  didn't do that


The monitor has a WT61P803,  8502 type MCU has Uart too, but so does buspirate, at some point I'd like to figure out if this MCU still works, or if it's stuck on something.

So little things like this are a way to get me into it. If I can't get the monitor working, that's just fine, it's not worth anything these days.

[DavidAlfa]

Check how your tests return NACK after writing 0xA9, 0xAB, 0xAD...
That's no good, it should ACK, like the other memory.
Anyways, you started reading the 16K eeprom at 0xA9, try with A0/A1.

You might need to send a stop condition between the blocks, as that's what deselects the device.
Sending a restart, then selecting a different block might jam something up, not sure, but the stop won't cause any harm.

Code: [Select]

[0xA0 0[0xA1 r:256][0xA2 0[0xA3 r:256]

Remember to check the datasheet, not all eeproms are the same, some use larger addressing.
Ex. the 24LC64, also has 8 blocks, but they're 1K each, so it uses 2 bytes for addressing.
Reading 1K from address 0 would be:

Code: [Select]

[0xA0 0 0[0xA1 r:256 r:256 r:256 r:256]
This could be dangerous on a small addressing eeprom, as you would be writing a first byte after the address 0.
The datasheet states the writing is triggered after the stop condition, so as long as you don't send a stop condition, it seems safe.
This would write the first byte:

Code: [Select]

[0xA0 0 0]
This shouldn't, because there's a restart condition:

Code: [Select]

[0xA0 0 0[0xA1 r:256]
So perhabs it's a 64K eeprom? Have you physically examined it?