7i95T PktUART: no usable TX output with either official bitfile

Hardware: 7i95T **rev A** (Efinix), LinuxCNC 2.10.0~pre0.6386.g3cd702c690
(buildbot deb), `hm2_modbus` + `mesambccc`. Slave: Delta C2000 VFD, 19200 8E1
RTU, address 1, parameters verified on its keypad.

Wiring per the 7i95T manual for 2-wire RS-485: TX+↔RX+ / TX−↔RX− bridged,
SG+/SG−/SGND to the drive, end-to-end continuity checked, bias resistors
fitted (2×2k2 to +5VP/GND), termination tried both ways (W23, rev A), both
polarities tried. A 7i84 runs error-free at 2.5 Mb on either serial port, so
transceivers, connectors and cabling are known good. A Saleae logic analyzer
at 24 MS/s sits directly on the RS-485 pair.

I believe I found three independent problems. As far as I can tell from the
forum, nobody has ever reported a *working* hm2_modbus setup on a 7i95T
(threads 51956 and 52858 both end without a success report), which would be
consistent with the following:

**1. TX drive enable polarity is not honored.**
Both official bitfiles (`7i95t_1v3pkt.bin`, PktUART v3 on serial 0, and
`7i95t_1pktv2d.bin`, v2 on serial 1 — md5-identical between mesact 2.1.8 and
the current mesanet.com 7i95t.zip) declare the TX enable pin as sec_pin 0x2,
which pins.c names "Drv Enable low". The hostmot2 driver never applies that
polarity: out of the box the RS-485 driver is **never enabled during
transmission** and the bus stays completely silent. Workaround found by
experiment: `setp hm2_7i95.0.uart.00.tx-drv-en.invert_output 1` — after which
the drive enable does toggle (visible on the analyzer). Should the GPIO
inversion be applied automatically by the driver from the sec_pin type?

**2. With DE fixed, no serial data ever appears on the line.**
Whatever is sent (hm2_modbus frames, or bytes pushed directly into the TX FIFO
via the raw interface at 0x6100 + sendcount at 0x6200), the analyzer shows a
**single solid low pulse per transmission, never a UART bit pattern** — even
for 0x55 payloads that should produce a dense alternating train. Pulse length
for an 8-byte frame is ~550 µs, which is ~88 bit-times at ~160 kbit/s, i.e.
about 8× the commanded 19200 (TX bitrate register readback is 483 for a
commanded 2304 baud, consistent with rate = baud × 2^24 / 80 MHz on the driver
side). So it looks like the serializer runs ~8× too fast AND the data path to
the TXData pad is stuck low during the burst. The slave never decodes
anything; the drive's own receiver decodes our DE edges as occasional 1–2 byte
ghost frames, which is what hm2_modbus then reports.

**3. The TX module eventually locks up entirely.**
After a series of hm2_modbus reloads and raw FIFO writes, the transmitter goes
completely dead — no pulses at all, not even via raw register writes — while
the watchdog has not bitten and all other functions (sserial, stepgen pins,
encoders) stay alive. Persists across hm2_modbus reloads; not yet re-tested
across a power cycle.

Also possibly related: at load time the "Drv Enable low" pin is listed on
implausible connectors (`TB3-16/TB3-17` for 1v3pkt, `TB4-22/23` shared with
TXData for 1pktv2d) where the .pin files say "Internal".

Has anyone ever seen the Efinix 7i95T PktUART actually transmit? Is a fixed
bitfile possible? Happy to test anything and to produce fresh analyzer
captures on request — this is for a lathe retrofit where the spindle VFD was
planned on this port.

Just tried a 7I95T (Rev. A) with

(MD5 checksum)

f1c9dff646bc7496e0883b3d0afbc05d  7i95t_1v3pkt.bin

And all works as expected with a GS10 VFD

PktUART pinout for this configuration is: