App Notes.

STM32H5 series microcontrollers include an I3C interface in the system bootloader programmed into ROM, allowing internal flash memory to be erased, programmed and verified over a two-wire I3C bus with no debug probe attached. This application note describes that interface, the connections required between a Binho Supernova USB host adapter and the target, and the procedure for programming a device. A complete reference utility written in Python accompanies the document. Measured results are given for an STM32H503 on a NUCLEO-H503RB board.

The system bootloader programmed into the ROM of STM32 microcontrollers offers an I2C interface on most families, allowing internal flash memory to be erased, programmed and verified over two wires with no debug probe attached. This application note describes that interface, the connections required between a Binho Pulsar USB host adapter and the target, and the procedure for programming a device. The same procedure and the same utility work with a Binho Supernova. A complete reference utility written in Python accompanies the document. Measured results are given for an STM32H503 on a NUCLEO-H503RB board.

The system bootloader programmed into the ROM of STM32 microcontrollers offers an SPI interface on many families, allowing internal flash memory to be erased, programmed and verified with no debug probe attached. This application note describes that interface, the connections required between a Binho Pulsar USB host adapter and the target, and the procedure for programming a device. It gives particular attention to the framing rule that separates a working host implementation from one that corrupts data, and to a method of driving reset from spare chip selects when no general-purpose pins are free. Measured results are given for an STM32H503 on a NUCLEO-H503RB board.

The current generation of Bosch Sensortec MEMS sensors offers a MIPI I3C interface alongside I2C and SPI. This application note shows how to bring one up from a Binho Supernova USB host adapter and the Binho I3C Target Board, and how to exercise the I3C features the sensor implements, without writing any firmware. It covers enumeration and dynamic address assignment, identifying a part from the bus rather than a lookup table, register access, streaming decoded sensor data, and in-band interrupts with no interrupt pin connected. Worked examples use the BMI323 inertial measurement unit and the BMP581 and BMP585 pressure sensors, and a reference Python utility that produced every output in this document is supplied.

The current generation of STMicroelectronics MEMS sensors offers a MIPI I3C interface alongside I2C and SPI. This application note shows how to bring one up from a Binho Supernova USB host adapter and the Binho I3C Target Board, and how to exercise the I3C features the sensor implements, without writing any firmware. It covers enumeration and dynamic address assignment, identifying a part from the bus rather than a lookup table, register access, streaming decoded sensor data, in-band interrupts with no interrupt pin connected, motion-triggered interrupts, and group addressing. Worked examples use the LSM6DSV six-axis IMU and the LPS22DF pressure sensor, and a reference Python utility that produced every output in this document is supplied.

The current generation of TDK InvenSense MEMS sensors offers a MIPI I3C interface alongside I2C and SPI, including the high data rate double data rate mode that most sensors leave out. This application note shows how to bring one up from a Binho Supernova USB host adapter and the Binho mikroBUS Adapter Board, and how to exercise the I3C features the sensor implements, without writing any firmware. It covers enumeration and dynamic address assignment, identifying a part from the bus rather than a lookup table, register access, streaming decoded sensor data, in-band interrupts with no interrupt pin connected, and an HDR-DDR transfer checked against the single data rate read of the same register. The worked example uses the ICM-45686 six-axis IMU, and a reference Python utility that produced every output in this document is supplied.

The ams OSRAM TMF8829 is a direct time-of-flight ranging sensor with a MIPI I3C interface alongside I2C and SPI. It reports a distance for each zone of a SPAD array rather than one distance for the field of view, up to 1536 zones per measurement, and it differs from a register-mapped sensor in three respects that determine how a host is written: its ranging firmware is downloaded over the bus at every power-up, results are returned through a FIFO rather than a register file, and a measurement is kilobytes rather than bytes. This application note shows how to bring one up from a Binho Supernova USB host adapter without writing any firmware. It covers enumeration and dynamic address assignment, forcing the bootloader and downloading the ranging application, selecting a zone configuration, the frame header field that determines the size of every zone, the transfer-length limit that a full-resolution frame exceeds, the row interleaving used by the two largest configurations, rendering the results, and an HDR-DDR frame transfer checked against the single data rate read of the same frame. The worked example uses the TMF8829 on a LIGHTRANGER 14 Click, and a reference Python utility that produced every output in this document is supplied.

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.

The OSFP-XD connector already permits I3C single data rate at 12.5 Mbit/s on the same two pins that carry the required 400 kbit/s I2C, and silicon vendors are shipping CMIS targets that use it. No published revision of CMIS specifies an I3C management interface, so a host driving one is following a private derivation rather than a standard. This application note brings up a CMIS module over I3C single data rate from a Binho Supernova, separates what carries over from the I2C binding unchanged from what is a genuine upgrade and what is not specified at all, and supplies a command that establishes which of two incompatible address wrap rules a given target implements.

SPIMCI, the SPI management interface added to CMIS in revision 5.3 for co-packaged optics, encodes acknowledgement as 00h. An idle bus, an unpowered module, or a target that was never armed therefore returns a byte perfect acknowledgement followed by zero data, and a bring-up that appears to succeed proves nothing. A second obstacle compounds it: the flow control byte count is not on the wire and is derived from registers that cannot be read until it is already known. This application note brings up a SPIMCI link from a Binho Pulsar or Supernova in a way that a silent bus cannot fool, and supplies a command that establishes both unknowns from the module's own checksum.

Updating firmware on an optical module is slow, and the obvious remedy is a faster management bus. Working through the CMIS access limits and the Table 10-4 timing parameters shows that the wire is not where the time goes: for a 1 MiB image the bus clock accounts for a small fraction of the total and the per-block hold-offs account for most of it. This application note derives the budget from the specification, states plainly which numbers are arithmetic and which would have to be measured, and supplies a command that times the access phases of a real module against the specification ceilings so that a host can find out which hold-offs its module actually takes.

The Binho Pulsar carries a CAN-FD controller and transceiver, and its USB virtual COM port can be switched into a mode that speaks SLCAN, the ASCII serial CAN protocol. That makes it a CAN-FD adapter for the standard tooling ecosystem rather than something that needs a bespoke SDK: python-can drives it through its stock `slcan` interface, and everything built on python-can follows. This application note switches a Pulsar into CAN-FD mode, works through the SLCAN protocol it then speaks, builds a second CAN-FD node on an Adafruit Feather M4 CAN Express so there is a real bus with two participants, and establishes what actually works: classic and FD frames in both directions, 64-byte payloads with bit-rate switching, DBC-driven decoding, and the CANopen, J1939 and ISO-TP stacks. Every output in this document is a real capture, and the reference node firmware, host utility and DBC are supplied.

A logic analyzer records what a controller did to a target that was present and answering. This application note takes such a recording and puts it back on a live bus from a Binho Pulsar, so an exchange observed once can be issued again on demand: to reproduce a fault, to drive a peripheral whose initialization sequence is known only from observation, or to exercise a target without its original host. It supplies the utility that does it twice over, once in Python on pyCosmicSDK and once in C++ on CosmicSDK, reading a Saleae I2C analyzer export, recovering the transactions from it and replaying them. The two are held to the same output: on the capture supplied with this document they print the same 155 lines. Every result is measured with the analyzer watching both the original and the replay, so the comparison is between two measurements rather than between a measurement and an intention. It is equally about what a replay cannot carry: a read is a fresh question to the current target, a refusal ends its own transaction, a repeated START survives on the wire but not in the timing, and a target that silently discards a write is indistinguishable from one that stored it.

Many SMBus and MCTP devices hold SCL low while they prepare a response. The Supernova's I3C engine cannot wait for that, so on its I3C port such a target used to lose bits. Adapter firmware 4.6.0 and pyCosmicSDK 1.6.0 add a mode in which legacy I2C transfers on the I3C port wait for the target, up to the SMBus 35 ms timeout. This note explains the mode, supplies a script that reads and writes a stretching target with it, and supplies the firmware of the reference target used to measure it: 3600 of 3600 reads correct at 100 kHz and 400 kHz over three runs, with the target stretching from 0 to 30 ms, and every stretched read correct up to the mode's ceiling of about 750 kHz. The script also runs the SMBus to I3C Basic detection flow of the PCI-SIG out-of-band management specification as far as the adapter can.

Some I2C targets, and some qualification plans, care how each SCL period is split between high and low, not only how many periods there are per second. Adapter firmware 4.6.0 and pyCosmicSDK 1.6.0 let a Binho Supernova or Pulsar set that split directly, from 20 to 80 percent high in steps of 10, and setting it also makes the bus frequency exact rather than rounded. This note explains the call, supplies a script that applies a ratio and prints what the adapter reports, and gives the ratios measured on the wire at 100 kHz and 400 kHz with a logic analyzer.

A DDR5 module carries an SPD5118 hub on its sideband bus: the SPD NVM, a temperature sensor, and a gateway to other devices on the module. This application note reads that hub from a Binho Supernova, in I2C mode and in I3C mode, and drives the RGB lighting controller of a Corsair DDR5 module, which sits behind the hub. It gives the register sequences, the I3C rates that returned correct data on one bench, a failure in I3C register writes that hung the bus until the module was power-cycled, and two Python scripts on pycosmicsdk.

The STMicroelectronics VD55G1 is a monochrome image sensor that can send its image over I3C, one line at a time, instead of over MIPI CSI-2. Each line is held for about 340 microseconds before the next one replaces it, and a single read issued from a PC over USB took 3.6 to 4.3 milliseconds on our bench, so a PC cannot read the image by issuing I3C reads itself. This application note shows how a Binho Supernova does those reads on the adapter, paced by a timer from one GPIO edge per frame, and returns whole frames to the PC over USB. On the bench it streams 160x120 8-bit frames at 9.8 frames per second. A Python capture utility and a live viewer are supplied; they produced the outputs in Sections 2 and 6.

A device that starts on an SMBus bus at 3.3 V and moves to I3C at 1.8 V needs the host to find it, check that nothing SMBus-only is left on the bus, lower the bus voltage and assign it a dynamic address. The Supernova does all of this from one I3C port. This note supplies a script that runs the five steps, with SETDASA or ENTDAA for the last one, and shows it on a bench where a second Supernova plays the I3C device: 20 of 20 runs with SETDASA and 20 of 20 with ENTDAA, with the bus high level measured at 3.34 V before the change and 1.79 V after it.

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.