- Welcome to Trenz Electronic GmbH Support Forum.
Recent posts
#21
Arrow USB Programmer2 / Re: Arrow Blaster 2 SMD versio...
Last post by Thorsten Trenz - February 24, 2026, 11:03:04 AMHi,
it is still available on request. Please write email to sales@trenz-electronic.de
Best Regards,
Thorsten Trenz
it is still available on request. Please write email to sales@trenz-electronic.de
Best Regards,
Thorsten Trenz
#22
Trenz Electronic FPGA Modules / TE0715-05-51I33 QSPI verificat...
Last post by koen_Schoutens - February 23, 2026, 10:42:21 AMDear,
Currently I'm using a TE0715-05-51I33 with the TEF1002 carrier.
Recently I updated the Petalinux version from 2020.2 -> 2024.2.
When updating the BOOT.BIN in the 2024.2 version, I get the following warning:
"File does not seem to match flash data. First mismatch at 0x00000000-0x00010000"
After checking the data, only byte 0 seems to be off. The device will boot with the new BOOT.BIN as expected.
Seeing as there used to be a issue with a similar qspi device, see:
https://wiki.trenz-electronic.de/display/PD/Petalinux+Troubleshoot
" Error Verifying contents on S15FL127S QSPI flash memory chip"
Could it be that this QSPI device needs a simmilar patch in 2024.2? The QSPI device the board is using:
S25FL256SAGBHI20
Kind regards.
Currently I'm using a TE0715-05-51I33 with the TEF1002 carrier.
Recently I updated the Petalinux version from 2020.2 -> 2024.2.
When updating the BOOT.BIN in the 2024.2 version, I get the following warning:
"File does not seem to match flash data. First mismatch at 0x00000000-0x00010000"
After checking the data, only byte 0 seems to be off. The device will boot with the new BOOT.BIN as expected.
Seeing as there used to be a issue with a similar qspi device, see:
https://wiki.trenz-electronic.de/display/PD/Petalinux+Troubleshoot
" Error Verifying contents on S15FL127S QSPI flash memory chip"
Could it be that this QSPI device needs a simmilar patch in 2024.2? The QSPI device the board is using:
S25FL256SAGBHI20
Kind regards.
#23
Arrow USB Programmer2 / Arrow Blaster 2 SMD version (T...
Last post by FvM - February 20, 2026, 03:02:43 PMHi,
a few months ago, TEI0005-02 appeared as active product in Trenz shop, now it doesn't seem to exist any more. What happened?
Regards
Frank
a few months ago, TEI0005-02 appeared as active product in Trenz shop, now it doesn't seem to exist any more. What happened?
Regards
Frank
#24
Trenz Electronic FPGA Modules / TEIB0006 + TEI0006 testing wi...
Last post by guirenaud - February 17, 2026, 08:49:41 AMHello
We are using the TEIB0006 carrier with the TEI0006 SOM module and start writing HDL code.
In the example design there s no implementation of the SFP modules. I there any other design example you can provide implenting those (and also I2C expenders communication) ?
Thanks for your help
Guillaume
We are using the TEIB0006 carrier with the TEI0006 SOM module and start writing HDL code.
In the example design there s no implementation of the SFP modules. I there any other design example you can provide implenting those (and also I2C expenders communication) ?
Thanks for your help
Guillaume
#25
Trenz Electronic FPGA Modules / Regarding GTH IP on TE0817
Last post by siddadd - February 17, 2026, 02:38:00 AMHi,
I am using the TE0817 SoM with the TEBF0818 carrier card. I am using the GTH on the FMC connector for transmitting and receiving data using 64b66b encoding/decoding. I am using the default GT ref clock of 100 MHz for a line rate of 3.6 Gbps. The Tx-Rx modules work in simulation using the Xilinx GTH IP. However, when testing on the board I notice that the Tx - Rx link disconnects arbitrarily causing data corruption. I have checked that the GTH QPLL locks and it stays locked. Also the Tx and Rx buffer status do not indicate any errors.
I have added ILA probes on the TX side and it seems that the issue could be at the Tx interface, since I notice glitches on the CDC FIFO interfacing with the GTH User Tx clock.
Is there any way to identify what could be the issue? Is there a way to measure the user clock frequencies on the oscilloscope? Are there any test points to probe some of the other GTH signals?
I am using the TE0817 SoM with the TEBF0818 carrier card. I am using the GTH on the FMC connector for transmitting and receiving data using 64b66b encoding/decoding. I am using the default GT ref clock of 100 MHz for a line rate of 3.6 Gbps. The Tx-Rx modules work in simulation using the Xilinx GTH IP. However, when testing on the board I notice that the Tx - Rx link disconnects arbitrarily causing data corruption. I have checked that the GTH QPLL locks and it stays locked. Also the Tx and Rx buffer status do not indicate any errors.
I have added ILA probes on the TX side and it seems that the issue could be at the Tx interface, since I notice glitches on the CDC FIFO interfacing with the GTH User Tx clock.
Is there any way to identify what could be the issue? Is there a way to measure the user clock frequencies on the oscilloscope? Are there any test points to probe some of the other GTH signals?
#26
Arrow USB Programmer2 / Re: USB Blaster III Compatibil...
Last post by Antti Lukats - February 15, 2026, 12:33:27 PMYes you can Update EEPROM to be compatible with USB Blaster III.
#27
Trenz Electronic FPGA Modules / Re: TE0720, TE0790: eFUSE prog...
Last post by andreas - February 12, 2026, 11:59:17 AMI'd like to implement your suggestions in the next test.
But how do I get one or two TE0790s right now? On your Web site they are out of stock and mine are broken.
But how do I get one or two TE0790s right now? On your Web site they are out of stock and mine are broken.
#28
Trenz Electronic FPGA Modules / Re: TE0720, TE0790: eFUSE prog...
Last post by Antti Lukats - February 12, 2026, 10:22:23 AMThis is really strange.
the best option would be to FULLY supply TE0790 from the carrier switches 3.4 BOTH off and VCCJTAG supplying pins 5,6
the best option would be to FULLY supply TE0790 from the carrier switches 3.4 BOTH off and VCCJTAG supplying pins 5,6
#29
Trenz Electronic FPGA Modules / Re: TE0720, TE0790: eFUSE prog...
Last post by andreas - February 11, 2026, 10:17:12 PMMy intention is to supply the TE0790 completely from our carrier.
But I use different Switch settings.
And I think our switch settings are at least not harmfull.
J2-5 is powered from TE0720 JM2-91 (VREF_JTAG, 3.3VIN)
J2-6 is open on our carrier.
S2D is Off (No connection from LDO 3V3 to 3.3V)
S2C is On (3.3V is directly connected to VIO. No 10R from J2-6!? Is that a problem?)
I attached the DIP-Switch part of the TE0790-03 Schematic.
As mentioned earlier, the error I see is sporadic.
But when an event hits me, my hardware is damaged. MACHXO on TE0790 and on TE0720 seem to be destroyed afterwards.
In case of an error the TE0790 is still detected as USB-Device, as long as I don't switch on VIO power.
The damaged TE0720-Boards do not activate there 3.3V output power.
The last error event hit me, when I already booted a secure linux system with attached TE0790 and tried to start a FSBL debug session from Vitis. (standalone)
The running system must have died, during the JTAG-Reset-Sequence.
What else can I check and test?
My next problem is, that I don't have TE0790s left.
During the last months this error damaged all our TE0790 (5 pieces).
But I use different Switch settings.
And I think our switch settings are at least not harmfull.
J2-5 is powered from TE0720 JM2-91 (VREF_JTAG, 3.3VIN)
J2-6 is open on our carrier.
S2D is Off (No connection from LDO 3V3 to 3.3V)
S2C is On (3.3V is directly connected to VIO. No 10R from J2-6!? Is that a problem?)
I attached the DIP-Switch part of the TE0790-03 Schematic.
As mentioned earlier, the error I see is sporadic.
But when an event hits me, my hardware is damaged. MACHXO on TE0790 and on TE0720 seem to be destroyed afterwards.
In case of an error the TE0790 is still detected as USB-Device, as long as I don't switch on VIO power.
The damaged TE0720-Boards do not activate there 3.3V output power.
The last error event hit me, when I already booted a secure linux system with attached TE0790 and tried to start a FSBL debug session from Vitis. (standalone)
The running system must have died, during the JTAG-Reset-Sequence.
What else can I check and test?
My next problem is, that I don't have TE0790s left.
During the last months this error damaged all our TE0790 (5 pieces).
#30
Trenz Electronic FPGA Modules / Re: TE0720, TE0790: eFUSE prog...
Last post by Antti Lukats - February 11, 2026, 01:22:51 PMTo our best knowledge, TE0790+TE0720 should not burn no matter how you connect them or what the DIP settings on TE0790 are. So it is a bit strange that you see damages.
But your dip settings doesnt seem right: you power the FT2232H with power from VCCJTAG and TE0790 IO buffer from the onboard LDO.
On-off-off-off would be better if you supply both VCC and VCCIO from your carrier.
But your dip settings doesnt seem right: you power the FT2232H with power from VCCJTAG and TE0790 IO buffer from the onboard LDO.
On-off-off-off would be better if you supply both VCC and VCCIO from your carrier.