// application note

AN0019 Building a CMIS I3C target on a Microchip dsPIC33AK and testing it with the Binho Supernova

A CMIS optical module answers its host as an I3C target, and the host reads it the way an I2C host does: write the byte address, repeated START, read. On the dsPIC33AK256MPS306 I3C peripheral the interrupt for that write arrives after the read header has already been answered, so a target that arms its reply from it NACKs every such read. This note shows where the byte address is available in time, how the firmware arms from the receive DMA instead, and the numbers measured from a Binho Supernova: 60 of 60 reads at 4 to 128 bytes, 300 of 300 with in-band interrupts on, after a reset too. It supplies the host-side test script and lists the behaviors of the peripheral and driver that a port has to plan for.

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

// outcomes

What you'll walk away with

A CMIS register model on the dsPIC33AK: paging, the section 8.2.15 unsupported-page override, the Appendix B.1.2 wrap inside a 128-byte segment, and an IBI that carries the Flags Summary byte 00h:4.
Answering write + Sr + read (combined) and write, STOP, read (split) at 2.5 MHz push-pull.
Dynamic address assignment, RSTDAA, and the Direct GET CCCs.
A host script that runs every check in this note from a Supernova.

Not covered: CDB, firmware download, HDR modes, and the module-side meaning of the CMIS control registers. The register image is static except for the page select and the bytes the host writes.

// background

Background

A CMIS module exposes a 256-byte window, Lower Memory plus one 128-byte page of Upper Memory, selected by a page byte at 00h:127. Over I2C the host writes a byte address and then reads with a repeated START. The I3C management interface being defined for CMIS keeps that access pattern, so a module built on an I3C target peripheral has to answer a read whose byte address arrived a few bit times earlier, in the same transfer.

That is easy when the peripheral hands each byte to firmware as it arrives. The dsPIC33AK256MPS306 I3C peripheral is command and response based instead: a received transfer is reported once, as a response, and a read is answered by a transmit command that must already be valid when the read header arrives. This note is about making those two meet.

// applicable devices

Applicable devices

Family	Example parts	Identifier	Basis
dsPIC33AK MPS with I3C	dsPIC33AK256MPS306 (EV02E57A DIM)	PID `02 36 43 4D 49 53`	Tested
dsPIC33AK MP without I3C	dsPIC33AK512MPS506 and family	-	Not applicable: no I3C peripheral
Other parts with the same I3C peripheral	-	-	Not tested

// what's covered

What's covered in the note

01 Introduction
02 System overview
03 Hardware setup
04 Software setup
05 Target firmware design
06 Procedure
07 Measured results
08 Troubleshooting

The full procedure, measured results, and reference code are in the PDF and the assets archive.

// materials

What you'll need

Binho Supernova USB host adapter for I3C, I2C, SPI & UART View product

Software Mission Control 3 or the Cosmic SDK (Python, C / C++ / C#). Get the software

Files The reference scripts and assets used in this note. Download the assets

// our edge

We don't just follow the I3C spec.

We don't watch from the sidelines. Plugfest after plugfest, our team is in the room where vendor I3C implementations come together — finding edge cases, debugging quirks, and validating real silicon against the spec.