I want to write a 24x512 eeprom from a .bin file on the PC.
As far as I can tell i2c eeprom write -f requires the file to be on the BP.
If that’s true, how do I get my .bin file into the Bus Pirate?
Hey!
Connect the bus pirate. Don’t connect a terminal. Copy the file to the USB drive that mounts on your computer. Eject the disk for good measure. Then you should be able to load the bin
Type ‘ls’ for a list of files on the internal storage.
Wow, I hadn’t realized the drive was presented except for firmware updates.
Thanks!
No problem. There is one drive for firmware updates, but in normal mode you have access to the 100MB internal storage. Here’s a screencast of the I2C EEPROM command in action.
I like how the USB disk is write-protected when you have a terminal session.
Next problem: Can you brick an eeprom?
The M24512-drmf3tg/k acted OK for dumping, and wrote once, supposedly OK.
Now it does this:
I2C> eeprom erase -d 24x512
24X512: 65536 bytes, 0 block select bits, 2 byte address, 128 byte pages
Erase: Writing 0xFF to all bytes…
Writing 256 blocks of 256 bytes each, 2 pages per block
Progress: [ ] 0.39%Error writing EEPROM at 256
Logic analyzer shows the last ACK’d byte (at the end of the first page?) , followed by only NAKs from there on:
You shouldn’t be able to brick an eeprom. Is there a WP write protect pin that needs to be held high?
I edited my previous reply to show logic analyzer output.
The WP pin floating allows write.
It looks like the eeprom can only write one 128-byte page at a time, and the BP wants to write 256 bytes. Is there a way to set that?
Good catch thank you. It should be using 128byte pages for 512k so there may be a bug. I will push a fix.
Are you using the latest firmware? I bought a set of “every” eeprom to test and pushed a bunch of fixes that cover a similar page size bug.
I can’t be sure until I’m at the computer, but just a temporary recommendation.
Latest firmware - yes.
I tried chopping my .bin file into 128-byte files. The first chunk starting at address 0 worked OK. The second file starting at address 0x80 overwrote starting at address 0.
I2C> eeprom write -d 24x512 -f 80.bin -v -s 0x80
24X512: 65536 bytes, 0 block select bits, 2 byte address, 128 byte pages
Write: Writing EEPROM from file 80.bin…
Warning: File smaller than EEPROM: writing the first 127 bytes
Writing 256 blocks of 256 bytes each, 2 pages per block
Progress: [##################################################] 100.00%
Write complete
OH - help says dump is the only command taking starting address.
Where in the source can I find the 256-byte block size for writes?
Here’s the part that does the write size decision:
S flag is for dump start, it does not yet support random writes.
512kbit is already set at 128 bytes
You can see the settings used here.
Here it is in the source:
In your output:
It knows it’s a 128 byte page but the erase reports 256 byte pages. There’s a logic issue I guess.
It is marked as tested, so I do have the device but I guess my testing wasn’t complete enough.
Is this the distinction between address block size (256) and page size (128)? The write call is using the page size from the eeprom args struct.
It could be. That’s confusing. I’ll update the debug output to be a bit more clear. It was very verbose but then a lot of the variables were renamed and enabling debug doesn’t fully work.
I read the data sheet and I don’t see anything abnormal. I assume I introduced a bug during testing updates.
I don’t have a 24x512 to hand, but I do have a 24xM01. I ran eeprom write -f (384-byte file) -d 24x512 and the Bus Pirate wrote it out in 128-byte chunks (2 address bytes, 128 data bytes, Stop condition).
Ah so there’s the issue. That should have a 256byte page size?
I don’t think there is an issue with the write size. I deliberately told the bus pirate it was a 24x512, and it used 128-byte page writes as you’d want. Next address was 0x00 0x80 (128) as you’d expect.
Ah okay, I understand. Sorry about that. Good confirmation, thank you so much!
No problem
I’ve put the Pulseview-compatible CSV here if anyone else fancies counting bytes to get themselves off to sleep.
