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:



 

This is with 2.9.10 and Master =2.10Pre (as of a week or so ago)

I also checked:

26b79f7bdef81b79ab3299925886b118 7i95t_1pktv2d.bin

and it worked as well, though it uses the other 7I95T RS-485 connection

Thanks Peter. Same md5 here for both files, Modbus block on TB4-14..17 with 1v3pkt, so neither the bitfile nor the wiring is the difference — and the transceiver, pad and connector are proven by the 7i84 running error-free in sserial on that same port.

Since it works for you with a plain setup, could you post the minimal config you tested on master — the mesambccc file and the HAL lines — and say whether tx-drv-en.invert_output appears in it? On my card the driver is never enabled during TX without it (checked on the analyzer), and I see no polarity handling for "Drv Enable low" in pins.c.

Which master build was it? Mine is 2.10.0~pre0.6386 (g3cd702c690).

One correction to my report: all symptoms, including the dead transmitter, were reproduced across several full power cycles, so it is not a stuck state.

I will re-flash 1v3pkt from the md5-verified file and redo a minimal test with a single hm2_modbus transaction and the analyzer directly on TB4-16/17, no raw register writes, and post the capture.

Here are the  hal/ini/mbccs files I used for testing:

 

I can check the exact master version but it's quite new
(late last week)

2.9.10 behaves identically

Hello,
I just checked your zip and the only real difference is you use 8N2, I need 8E1 (and 38400 vs 19200bps).
Could that be the problem ?

Thanks !

Unlikely, The V2 firmware does not support 2 stop bits and it runs the same
(the driver complains that it cannot set 2 stop bits so drops back to 1 stop bit)

I can try the same setup with 1 stop bit but I doubt that's the issue

Ok for the stop bits, what about the parity ?

I've gone through the parity options before but Its been a while

That said, I have not seen  any other parity complaints,

I can try and duplicate this sometime this week but I think it's something more basic.

Edit:

Just tried the GS10 at 8E1 (still 38400 baud) and it works as expected on master.