// application note

AN0008 Bringing up a CMIS optical module over I2C with the Binho Supernova

An optical transceiver is managed over a two-wire interface whose meaning depends on a page selection made in an earlier transaction. A generic I2C decode returns bytes that cannot be interpreted without that context, so a bring-up that looks successful can be reading the wrong part of the module. This application note walks the sequence a CMIS host runs at module discovery from a Binho Supernova or Pulsar, in the order a host runs it, and ends on the strongest check available together with the condition that check needs before it means anything. A reference Python utility that implements the CMIS register access layer over any of the three management transports is supplied.

Products: Binho Supernova Binho Pulsar
Protocols: I2C
Topics: CMIS
Revision: Rev 1.0 · November 6, 2026

// outcomes

What you'll walk away with

By the end of this document a reader with the hardware in front of them will have detected a module on the management bus, polled it for readiness, decoded its identity and module state, read its temperature and supply monitors, discovered its maximum access length from its own advertisement, read its vendor block from Upper Memory, and validated the Page 00h checksum.

The document covers the I2C management interface (I2CMCI), which CMIS Appendix B.2 specifies normatively and which every deployed module implements. The SPI interface is covered in AN0010 and an I3C binding in AN0009. Firmware update, the Common Data Block and performance monitoring are out of scope; the firmware update timing question is AN0011.

// background

Background

A CMIS exchange on a wire is a paged, stateful conversation. A single register read is a write of a byte offset, a repeated START, and a read. What that offset means depends on a bank and page selection that may have been written in an earlier transaction, may have been silently overridden by the module, and rolls over inside its own 128 byte segment rather than across the address space.

That is why "the module answered" is not the same as "the module is working", and why the first hour of a bring-up is so often spent debugging a host against bytes that were never what the engineer thought they were.

This note establishes, from a Binho USB host adapter and nothing else, that a module is present, willing to be read, correctly paged, and internally self consistent. It ends on a checksum the module itself computed, because that is the outcome an absent or unpowered target is least able to produce by accident. Section 4 gives the one case where it can, and the condition that rules the case out.

// applicable devices

Applicable devices

Item	Role	Basis
Binho Supernova	Host adapter, I2C controller	Exercised, Section 8
Binho Pulsar	Host adapter, I2C controller	Not exercised. The SDK differs only in taking a bus selector
Any CMIS managed module	Target at address 0x50	Not exercised. See the callout below
Saleae Logic with the CMIS I2CMCI analyzer	Optional bus observer	Analyzer is in development

The procedure has not been run against an optical module. It has been run end to end against a second Supernova armed as an I2C target at 0x50, holding a CMIS 5.3 image. That exercises the host, the register access layer, the paging and the checksum, all of which are the subject of this document. It does not exercise anything that belongs to a module: hold-off behavior, page support, or the roll-over rule. Findings are attributed to the layer they belong to throughout, and Section 8.3 lists what a module would still have to confirm. It becomes revision 1.0 when it has been run against one.

// what's covered