Split EEPROM Writes at Physical Page Boundaries

A buffer shorter than an EEPROM’s page size can still cross a page boundary if it starts near the end of the page. A driver that checks only total payload length can therefore overwrite data in an unexpected location. Base each transfer on the remaining space from the actual starting address.

Read the device’s boundary behavior

Microchip’s AT24C256C page-write documentation specifies a 64-byte page and explains that its internal address wraps within the same page when the boundary is crossed. That behavior makes software boundary management essential. Confirm the corresponding details in the selected device’s PDF datasheet.

Keep page size, address width, total capacity and write-completion behavior in the driver’s device configuration. Do not assume that a larger-capacity replacement retains all four properties. The memory’s bus address and its internal byte address are also different fields.

Calculate each chunk from its offset

For a hypothetical 64-byte page and a start address of 60, only four bytes remain in that page. A 12-byte payload therefore needs a four-byte transfer followed by an eight-byte transfer into the next page. Sending all 12 bytes as one page write would not describe the intended contiguous update for the example device.

The general chunk size is the smaller of the remaining payload and the page size minus the current address modulo the page size. After the write completes according to the device protocol, advance both address and buffer position by that chunk. Also reject requests that exceed total capacity.

Test boundaries rather than only aligned buffers

Use test patterns that make address errors obvious. Cover the first byte, final byte of a page, a transfer ending exactly on a boundary and a transfer crossing several pages. Include the end of the whole device address space as a separate limit.

Read back the updated region and surrounding bytes. Checking only the requested buffer can miss collateral changes where wrapped data landed. Preserve known guard patterns outside the intended range so that unintended writes have an observable result.

Keep completion and interruption separate

Boundary splitting prevents a particular addressing error; it does not make a multi-page update atomic. Define how the application recognizes an interrupted update and which data remain valid. Use a suitable record scheme when consistency across pages matters.

Retain the page geometry and boundary test cases with the driver. When changing memory parts, rerun those targeted cases along with the new completion behavior. A successful write at address zero is useful but provides little evidence that an unaligned production record will be stored correctly.