FPGA CN8 Input faulty?

[Graeme Jury]

Hello Group,

The Problem:
I'm pretty sure that I have blown the CN8 input on my HL2 FPGA. Both Quisk and piHPSDR report "Tx Inhibit" on screen. This of course means that I can't transmit.

What I was doing:
I built an interface to 'opto isolate' the HL2 from an AH4 tuner fed from the N2ADR I/O Board which worked very well but I noticed that although Quisk responded to the signals back from the Tuner via the I/O board and started and stopped RF etc., piHPSDR only supplied the tune start and I needed to guess when tune was complete and stop the tune button. I was mindful of requests not to bother the PC radio developers with personal modification requests so I looked for a programming solution using the Pico in the I/O board. I decided that at the point where the RF stop is called in the AH4 tuner library I should inject a pulse on CN8 to inhibit TX, causing piHPSDR to revert to receive. To achieve this I used a connection from GPIO22_Out6 via J6 pin 6 to CN8 where it appeared on the I/O Board. J6 pins are open collector outputs and simply should have taken CN8 to ground when activated and floated it when not and I did not expect any issues. I am as certain as I can be that I did not apply 5 volts to the CN8 input.

What I have tried:
Removed all external boards leaving only HL2 board
Voltage on CN8 = 3.26
Voltage on actual FPGA Pin = 3.26
Full shutdown and restart of HL2 and PC
Tried reloading the bitfile using Quisk but received the following error:
*** Quisk started on linux at Sun Apr 19 16:25:50 2026
Can not find MIDI device Pico MIDI 1
Traceback (most recent call last):
  File "/opt/quisk/quisk_widgets.py", line 593, in OnButton
    self.command(event)
  File "hermes/quisk_hardware.py", line 1128, in ProgramGateware
    state = QS.set_params(hermes_pause=1)
            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
SystemError: more argument specifiers than keyword list entries (remaining format:'i')

Can you help with:
I can live without Tx Inhibit (just) is there any way to disable this feature without adjusting the FPGA firmware?

If the firmware needs to be modified, I can't do it and I don't expect anyone else to do it for me and thus will become the owner of a nice receiver only.

Any other suggested checks that I can make?

Any comments on the idea of pulsing CN8 to take piHPSDR out of Tx when tuning.

Thanks for taking the time to read this,

73, de Graeme ZL2TE

[DL1YCF]

The question (that I cannot answer at the moment) is whether this input is actually processed
by the FPGA (e.g. stops the FPGA from going TX) or is just reported upstream to piHPSDR/Quisk.

In the latter case it is certainly possible just to ignore that bit, in case you have blown the
input such that it is constantly active. So if you un-check the „Enable TxInhibit Input“ check box
in the radio menu, you for sure do not get the „TX Inhibit“ message, but does it go TX?

In the first case, you are less lucky.

73, DL1YCF.

> --
> You received this message because you are subscribed to the Google Groups "Hermes-Lite" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to hermes-lite...@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/hermes-lite/4af3d1f4-5407-41b4-b69c-39adc545df62n%40googlegroups.com.

[Graeme Jury]

Hello Christoph,

Thanks for your response. I'm afraid that I was not lucky and the FPGA is controlling the TX Inhibit so disabling "Enable Txinhibit Input" removed the "Tx Inhibit" message from the spectagram screen but still does not allow the HL2 to go to transmit. Nice try and thanks for your suggestion.

73, Graeme ZL2TE

[Reid Campbell]

Hi Graeme,

Sorry to hear about your problem. If the CN8 input has been destroyed, it would be possible to build a special Gateware, which would ignore that input. All the tools to do this are available on line, for free, from the FPGA vendor (I think that is Intel now?).

For future reference, there is a spare I/O on the Pico, GPIO5, which is not used in the design. That could be used as a control line for CN8, allowing the Pico to inhibit transmission if required.

Cheers

Reid
MI0BOT

To view this discussion visit https://groups.google.com/d/msgid/hermes-lite/c8e11789-2c07-478b-8f74-cc7e9d27131en%40googlegroups.com.

[Steve Haynal]

Hi Graeme,

Building custom gateware is probably your best bet. I have several HL2s with bad FPGAs IO which I have worked around with custom gateware.

73,

Steve

kf7o

[Graeme Jury]

Thanks for the responses Guys,

@Reid: I'm sure the CN8 (fpga pin 25) is destroyed and I guess that I can figure out how to program another pin. In the early days we had to use the ide to program the HL and somewhere (I have moved to a retirement village so everything is not in its usual place) I have a programmer. I completely missed the GPIO5 pin which of course I should have used. Thanks for this and when I get things restored I will use it.

@Steve: In the file "pins.tcl" there is no location assignment for pin 26. Physically it is tied to 3v3 on the pcb but I suspect that this is for noise immunity. Can I lift pins 25 and 26, leave 25 floating and cross wire pin 26 to the pin 25 pad? If pin 25 (CN8) is bad anyway is it ok to float it or should I cross wire this to 3v3 for noise immunity? As Reid suggested I can install the IDE to reprogram the FPGA and if you confirm that my hardware suggestion is correct, I just need to figure out how to shift the code that inputs from pin 25 to now use its input from pin 26. Will there already be code for pin 26 that I need to disable? Sorry to have to ask this but I have only ever used your bitfiles and uploaded them as is into my HL2 FPGA so I'm in completely new territory here.

Its been a bit of a blow as I had my opto isolated HL2 to AH4 tuner interface working perfectly and was just going to write it up for the group when I had the CN8 brainwave and carelessly blew the input before I could fully test it and what is more troublesome is that I still can't figure out what I did to blow it.

73, Graeme ZL2TE

[Steve Haynal]

Hi Graeme,

The pins are defined in gateware/boards/hl2b5up/pins.tcl. You can either move PIN_25 to another pin there or just disable io_tx_inihibit in gateware/variants/hl2b5up_main/hermeslite.v by connecting to a constant.

    .io_tx_envelope_pwm_out_inv(                     ),
    .io_tx_inhibit             (1'b1              ),

    .io_id_hermeslite          (io_cn9               ),

73,

Steve

kf7o

[Graeme Jury]

Thanks for the info Steve, I have downloaded Quartus 19.1 and ordered a USB Blaster cable as during my move a lot of my gear was disposed of including my blaster. I hope that this one works. I am going to keep the TX Inhibit function as this is necessary for my tuner operation and would be grateful if you could confirm that pin 26 is actually a spare (it is not listed in the pins.tcl file so I'm assuming that it is) and I can lift it off its current 3v3 pad and cross wire it to the pad for pin 25. As you have explained I will simply change 25 to 26 in the pins.tcl file.

73, Graeme zl2te

[Graeme Jury]

Hello Group,

I have downloaded Quartus v 19.1 and ran into an issue where all the text boxes etc. seemed to be writing white on white when selected and I had to fix this before I could proceed. I used 19.1 because I understand that my USB Blaster cable won't work with later versions.

The fix:
This error message is the key

libstdc++.so.6: version `CXXABI_1.3.8' not found

What’s happening:

• Intel Quartus Prime 19.1 ships its own outdated libstdc++.so.6
• My system (Ubuntu 24.04 / Mint 22.3) uses a much newer libstdc++
• GTK / gdk-pixbuf (system libraries) try to load SVG support
• That loader depends on modern C++ ABI symbols
• Quartus forces its old libstdc++ → ABI mismatch → rendering breaks

Step-by-step fix:

1. Locate the offending library

    ls /home/gvj/intelFPGA_lite/19.1/quartus/linux64/libstdc++.so.6

2. Rename it

    mv /home/gvj/intelFPGA_lite/19.1/quartus/linux64/libstdc++.so.6 \
       /home/gvj/intelFPGA_lite/19.1/quartus/linux64/libstdc++.so.6.bak

3. Do the same for related libs

    mv /home/gvj/intelFPGA_lite/19.1/quartus/linux64/libgcc_s.so.1 \
       /home/gvj/intelFPGA_lite/19.1/quartus/linux64/libgcc_s.so.1.bak

Why this works:

Linux dynamic linker behavior:

    Quartus prepends its own linux64/ directory to LD_LIBRARY_PATH

    That forces old libraries to override system ones

    By removing them, the system falls back to:

        /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (correct, modern)

Hope this helps anyone trying to get Quartus running on Linux Mint.

I have discovered that I can't use pin 26 as its an internal pin so I'm currently looking for the nearest spare pin to 25. I did get Quartus to compile hl2b5up_main.rbf with no errors using the original file so well on the way.

73, Graeme zl2te

[Reid Campbell]

Hi Graeme,

Can't you upload the bit files via Ethernet? I would normal do this with SparkSDR and would allow you to use the latest Quartus.

Cheers

Reid
MI0BOT

To view this discussion visit https://groups.google.com/d/msgid/hermes-lite/8e85b4c7-0b83-4d37-ada1-566ba8fd9bc5n%40googlegroups.com.

[Graeme Jury]

Today I finally got my hermes-Lite running correctly again - what a relief! I repurposed TP9 (Pin 127) as it did not appear to have any working code attached and was probably used for early stage debugging. I lifted pin 25 and left it floating and jumpered TP9 to J28 to connect it to CN8. Then I altered the pins.tcl file to reflect the changes and compiled, renamed the hermeslite.rbf output file to hl2b5up_main_gvj.rbf and uploaded as you suggested Reid using SparkSDR and after testing, everything is working. It was a bit of a mission for an 84 year old who has never programmed an FPGA before but thanks to the help I received, I made it.

Now back to the job I was doing before my faux pax, Reid, I don't have a windows machine so have never run Thetis so would you mind answering; Does Thetis send a 1 or a 2 (Tune or Bypass) to the N2ADR Pico I/O board when the spot tune button is clicked and do you check the register for RF off and tune success or failure? Just wondering as a Tx inhibit pulse would be relevant in your case too if no tune complete detect.

Again thanks everyone for the support, I am a very relieved and happy guy.

73 de Graeme zl2te

[Reid Campbell]

Remember Graeme, age is only a number - great work sorting that out.

Here is a link to a bit of a discussion on the tuner protocol - https://github.com/mi0bot/OpenHPSDR-Thetis/issues/127

Basicity I send a 0x01 and wait for the 0xEE, before applying RF. I then wait from the tune to complete (I can't remember the code for that, maybe 0) or timeout.

I think it is all working but you are dependant on the Pico code. I did find the default Pico code had it's own timeout which caused the tune operate to terminate after 4-5 seconds.

I would like to do more to support the I/O Broad from within Thetis but time is limited at the minute.

Cheers

Reid
MI0BOT 

To view this discussion visit https://groups.google.com/d/msgid/hermes-lite/79f422d9-fa64-486f-bc26-98b4cd9dd36en%40googlegroups.com.

[Graeme Jury]

Hello Reid, thanks for the link and I see that you have already gone above the call and implemented an 'RF on' in response to 0xEE. Although Jim has done a full implementation of the register contents, the only thing asked of PC sdr developers was to send tune level RF and 0x01 to the register when the tune button was clicked and it stayed that way until the tuner was finished, then you manually clicked the tune button to toggle RF off. Once the Pico had received a tune start it was up to its code to handle the tune. What triggered my burnt input event was coding the Pico to send a TxInhibit pulse to automatically switch the tune button off when the tuner signaled it was complete.

I don't want to get too deep into this in this thread and as I get things finalized will post more detail but you are providing what is needed as is Jim and Christoph. I have not fully tested Alan's SparkSDR yet.

73, Graeme zl2te

[Steve Haynal]

Hi Graeme,

TP9 (Pin 127) is a good choice. This is one of the extra clock/input-only pins which was never used. The input/output pins are in short supply. Great news that you got it working again!

73,

Steve

kf7o