Firmware:
7.00 (regression — works on 6.06) Hardware: VESC HW 60; STM32 I²C on SWDIO/SWCLK pins Peripheral: HT16K33 LED-matrix controller @ 0x70
Summary:
On FW 7.00, the first i2c-tx-rx transaction issued after i2c-start (i.e. the first write on a freshly initialised/muxed I²C bus) is silently swallowed — it never reaches the device. The same code delivered that first message correctly on 6.06.
Impact / how it surfaced:
The display init on the Blacktip DPV sends the HT16K33 oscillator-enable (0x21) once right after i2c-start. On a cold boot under 7.00 that single write is lost, the controller's oscillator never starts, and the panel stays dark. A warm :reset masks it because the bus is already muxed (and the chip stayed powered), so no message is swallowed.
Workaround:
Sending the first command twice fixes it — the first write absorbs the drop, the second reaches the device:
(i2c-start 'rate-400k 'pin-swdio 'pin-swclk)
(i2c-tx-rx 0x70 (list 0x21)) ; swallowed
(i2c-tx-rx 0x70 (list 0x21)) ; delivered
(see https://github.com/vedderb/vesc_pkg/pull/94/changes#diff-8ed3a40d93d71399cc18a949e914fed4bf8c1f3191c3a7b781464fc10bfb5969R1574 for a tested implementation of the fix)
Expected:
the first i2c-tx-rx after i2c-start is delivered, as on 6.06.
Actual:
the first transaction is dropped; subsequent ones succeed.
Firmware:
7.00 (regression — works on 6.06) Hardware: VESC HW 60; STM32 I²C on SWDIO/SWCLK pins Peripheral: HT16K33 LED-matrix controller @ 0x70
Summary:
On FW 7.00, the first i2c-tx-rx transaction issued after i2c-start (i.e. the first write on a freshly initialised/muxed I²C bus) is silently swallowed — it never reaches the device. The same code delivered that first message correctly on 6.06.
Impact / how it surfaced:
The display init on the Blacktip DPV sends the HT16K33 oscillator-enable (0x21) once right after i2c-start. On a cold boot under 7.00 that single write is lost, the controller's oscillator never starts, and the panel stays dark. A warm
:resetmasks it because the bus is already muxed (and the chip stayed powered), so no message is swallowed.Workaround:
Sending the first command twice fixes it — the first write absorbs the drop, the second reaches the device:
(see https://github.com/vedderb/vesc_pkg/pull/94/changes#diff-8ed3a40d93d71399cc18a949e914fed4bf8c1f3191c3a7b781464fc10bfb5969R1574 for a tested implementation of the fix)
Expected:
the first i2c-tx-rx after i2c-start is delivered, as on 6.06.
Actual:
the first transaction is dropped; subsequent ones succeed.