- Welcome to Trenz Electronic GmbH Support Forum.
Recent posts
#71
Trenz Electronic FPGA Modules / Re: TEI0022 DataStorm FPGA DDR...
Last post by MR - September 18, 2024, 12:14:10 AMThanks for the reply, but this design only has the HPS memory. I am looking for a design that utilizes the DDR3 attached to the non-HPS pins.
Thanks,
Matt
Thanks,
Matt
#72
EDDP-EDPS Support / Re: TE0950 Versal support on V...
Last post by M Kirberg - September 17, 2024, 10:18:27 AMHi,
you need the extensible platform flow.
Please write to trenz support email then I can provide you with a working TE0950 AI example code.
br
you need the extensible platform flow.
Please write to trenz support email then I can provide you with a working TE0950 AI example code.
br
#73
Trenz Electronic FPGA Modules / Re: QSPI Flash Issues on TE074...
Last post by JH - September 16, 2024, 09:05:52 AMHi,
your programming steps looks fine. You programmed QSPI with SD insert, so it was QSPI boot mode, but with older your SDK Version it's no matter, problems are only with newer one. When you change Boot Mode to JTAG only(without SD and DIP S1-1 OFF, than it should also be possible with newer Vivado/Vitis Version(but you need correct project with correct FSBL in this case too)).
Your Boot.bin should normally also be fine when it boots from SD.
At the moment I would expect it should works.
Do you see something on uart when you try to reboot with reset button from TE0790 programmer?
Can you tell me which assembly variant of the TE0745 you has or alternatively the serial number of the module(it's on the small sticker with QR Code)?
Can you try out one time our reference design boot.bin please?
https://wiki.trenz-electronic.de/display/PD/TE0745+Test+Board
-->direct Download link:https://shop.trenz-electronic.de/trenzdownloads/Trenz_Electronic/Modules_and_Module_Carriers/5.2x7.6/TE0745/Reference_Design/2023.2/test_board/TE0745-test_board-vivado_2023.2-build_4_20240220094718.zip
Download includes also prebuilt binaries, use hello TE0745 example Boot.bin at first.
br
John
your programming steps looks fine. You programmed QSPI with SD insert, so it was QSPI boot mode, but with older your SDK Version it's no matter, problems are only with newer one. When you change Boot Mode to JTAG only(without SD and DIP S1-1 OFF, than it should also be possible with newer Vivado/Vitis Version(but you need correct project with correct FSBL in this case too)).
Your Boot.bin should normally also be fine when it boots from SD.
At the moment I would expect it should works.
Do you see something on uart when you try to reboot with reset button from TE0790 programmer?
Can you tell me which assembly variant of the TE0745 you has or alternatively the serial number of the module(it's on the small sticker with QR Code)?
Can you try out one time our reference design boot.bin please?
https://wiki.trenz-electronic.de/display/PD/TE0745+Test+Board
-->direct Download link:https://shop.trenz-electronic.de/trenzdownloads/Trenz_Electronic/Modules_and_Module_Carriers/5.2x7.6/TE0745/Reference_Design/2023.2/test_board/TE0745-test_board-vivado_2023.2-build_4_20240220094718.zip
Download includes also prebuilt binaries, use hello TE0745 example Boot.bin at first.
br
John
#74
UltraScale / Re: TE0803 SOM - linux BSP
Last post by JH - September 16, 2024, 08:22:03 AMHi,
we have a reference design with petalinux(yocto based) template for TE0803 together with our TEBF0808 carrier. Documentation and downloads:
https://wiki.trenz-electronic.de/display/PD/TE0803+StarterKit
We didn't have buildroot examples, sorry.
br
John
we have a reference design with petalinux(yocto based) template for TE0803 together with our TEBF0808 carrier. Documentation and downloads:
https://wiki.trenz-electronic.de/display/PD/TE0803+StarterKit
We didn't have buildroot examples, sorry.
br
John
#75
UltraScale / TE0803 SOM - linux BSP
Last post by flatmax - September 15, 2024, 05:07:14 AMHi there,
Is there a Linux BSP for the TE0803 module ?
If not, what are people using to build Linux for the TE0803 module ?
Is there buildroot support ?
thanks
Matt
Is there a Linux BSP for the TE0803 module ?
If not, what are people using to build Linux for the TE0803 module ?
Is there buildroot support ?
thanks
Matt
#76
Trenz Electronic FPGA Modules / Re: Generating FSBL for TE0720...
Last post by JH - September 13, 2024, 01:14:39 PMHi,
TE0720-03-1CR and TE0720-04-61Q33MA use different DDR with different size.
Did you checked that your project use correct PS configuration?
You can import our FSBL with trenz modification as template into Vitis as local repository and use GUI:
https://wiki.trenz-electronic.de/display/PD/Vitis#Vitis-Includelocalrepositories
with newer Vivado/Vitis/Petalinux we offer also a patch for petalinux:
https://wiki.trenz-electronic.de/display/PD/TE0720+Test+Board
https://wiki.trenz-electronic.de/display/PD/TE0720+Test+Board#TE0720TestBoard-FSBLpatch(alternativeforvitisfsbltrenzpatch)
But this does work only with corresponding petalinux version.
But at the moment I would expect you use wrong PS configuration for memory.
PS Memmory setup is set to "MT41J64M16 JT-125G" on TE0720-03-1CR and "MT41J256M16 RE-125" on TE0720-04-61Q33MA. memory configuration will be done with fsbl and linux only need to know size, that's the reason why it works in the other way(or boot.bin and your linux files) and linux use less ddr.
br
John
TE0720-03-1CR and TE0720-04-61Q33MA use different DDR with different size.
Did you checked that your project use correct PS configuration?
You can import our FSBL with trenz modification as template into Vitis as local repository and use GUI:
https://wiki.trenz-electronic.de/display/PD/Vitis#Vitis-Includelocalrepositories
with newer Vivado/Vitis/Petalinux we offer also a patch for petalinux:
https://wiki.trenz-electronic.de/display/PD/TE0720+Test+Board
https://wiki.trenz-electronic.de/display/PD/TE0720+Test+Board#TE0720TestBoard-FSBLpatch(alternativeforvitisfsbltrenzpatch)
But this does work only with corresponding petalinux version.
But at the moment I would expect you use wrong PS configuration for memory.
PS Memmory setup is set to "MT41J64M16 JT-125G" on TE0720-03-1CR and "MT41J256M16 RE-125" on TE0720-04-61Q33MA. memory configuration will be done with fsbl and linux only need to know size, that's the reason why it works in the other way(or boot.bin and your linux files) and linux use less ddr.
br
John
#77
Trenz Electronic FPGA Modules / QSPI Flash Issues on TE0745
Last post by alaney - September 13, 2024, 01:10:22 PMI am trying to get my system to boot from QSPI flash, but am having issues. where this is what I have tried:
1) I have updated the CPLD to variant 2 allowing JTAG/QSPI/SD Card
2) My main project (bare metal) is using Vivado/Vitis 2024.1 where if I understand your wiki information the Vitis/SDK version has varying degrees of issues when programming the QSPI flash.
3) From this wiki I have installed 2017.2 (seemed the version with the least issues to me) and created an unrelated SDK fsbl application targeting a ZC702 board. I have only done this so that SDK then allows me to use the flash program application. I have then referenced the BOOT.bin file from my 2024.1 project in the flash programming tool and programed/verified successfully. Here is the console op during flashing:
cmd /C program_flash -f \
G:\Vitis_Workspace_2024\SW_Application\BOOT.bin \
-offset 0 -flash_type qspi_single -blank_check -verify -cable type xilinx_tcf url \
TCP:127.0.0.1:3121
****** Xilinx Program Flash
****** Program Flash v2017.2 (64-bit)
**** SW Build 1909853 on Thu Jun 15 18:39:09 MDT 2017
** Copyright 1986-2017 Xilinx, Inc. All Rights Reserved.
Connecting to hw_server @ TCP:127.0.0.1:3121
Connected to hw_server @ TCP:127.0.0.1:3121
Available targets and devices:
Target 0 : jsn-JTAG-ONB4-251633006C35A
Device 0: jsn-JTAG-ONB4-251633006C35A-4ba00477-0
Retrieving Flash info...
Initialization done, programming the memory
BOOT_MODE REG = 0x00000001
WARNING: [Xicom 50-100] The current boot mode is QSPI.
If flash programming fails, configure device for JTAG boot mode and try again.
f probe 0 0 0
Performing Erase Operation...
Erase Operation successful.
INFO: [Xicom 50-44] Elapsed time = 7 sec.
Performing Blank Check Operation...
0%...10%...20%...30%...40%...50%...60%...70%...80%...90%...100%
INFO: [Xicom 50-44] Elapsed time = 39 sec.
Blank Check Operation successful. The part is blank.
Performing Program Operation...
0%...10%...40%...70%...80%...100%
Program Operation successful.
INFO: [Xicom 50-44] Elapsed time = 33 sec.
Performing Verify Operation...
0%...10%...20%...30%...40%...50%...60%...70%...80%...90%...100%
INFO: [Xicom 50-44] Elapsed time = 39 sec.
Verify Operation successful.
Flash Operation Successful
4) If I then power cycle board with SD card fitted and have all S1 switches set to OFF position on your TEB0745 development board it fails to boot. NOTE: I still have the CPLD programmed with variant 2
5) If instead, I copy the same BOOT.bin file onto an SD card, set S1-1 to on, power cycle brd then it boots correctly.
I am no expert with the SDK/Vitis tools so am sure I am doing something obviously incorrect. Can you please help me out.
Thanks!
1) I have updated the CPLD to variant 2 allowing JTAG/QSPI/SD Card
2) My main project (bare metal) is using Vivado/Vitis 2024.1 where if I understand your wiki information the Vitis/SDK version has varying degrees of issues when programming the QSPI flash.
3) From this wiki I have installed 2017.2 (seemed the version with the least issues to me) and created an unrelated SDK fsbl application targeting a ZC702 board. I have only done this so that SDK then allows me to use the flash program application. I have then referenced the BOOT.bin file from my 2024.1 project in the flash programming tool and programed/verified successfully. Here is the console op during flashing:
cmd /C program_flash -f \
G:\Vitis_Workspace_2024\SW_Application\BOOT.bin \
-offset 0 -flash_type qspi_single -blank_check -verify -cable type xilinx_tcf url \
TCP:127.0.0.1:3121
****** Xilinx Program Flash
****** Program Flash v2017.2 (64-bit)
**** SW Build 1909853 on Thu Jun 15 18:39:09 MDT 2017
** Copyright 1986-2017 Xilinx, Inc. All Rights Reserved.
Connecting to hw_server @ TCP:127.0.0.1:3121
Connected to hw_server @ TCP:127.0.0.1:3121
Available targets and devices:
Target 0 : jsn-JTAG-ONB4-251633006C35A
Device 0: jsn-JTAG-ONB4-251633006C35A-4ba00477-0
Retrieving Flash info...
Initialization done, programming the memory
BOOT_MODE REG = 0x00000001
WARNING: [Xicom 50-100] The current boot mode is QSPI.
If flash programming fails, configure device for JTAG boot mode and try again.
f probe 0 0 0
Performing Erase Operation...
Erase Operation successful.
INFO: [Xicom 50-44] Elapsed time = 7 sec.
Performing Blank Check Operation...
0%...10%...20%...30%...40%...50%...60%...70%...80%...90%...100%
INFO: [Xicom 50-44] Elapsed time = 39 sec.
Blank Check Operation successful. The part is blank.
Performing Program Operation...
0%...10%...40%...70%...80%...100%
Program Operation successful.
INFO: [Xicom 50-44] Elapsed time = 33 sec.
Performing Verify Operation...
0%...10%...20%...30%...40%...50%...60%...70%...80%...90%...100%
INFO: [Xicom 50-44] Elapsed time = 39 sec.
Verify Operation successful.
Flash Operation Successful
4) If I then power cycle board with SD card fitted and have all S1 switches set to OFF position on your TEB0745 development board it fails to boot. NOTE: I still have the CPLD programmed with variant 2
5) If instead, I copy the same BOOT.bin file onto an SD card, set S1-1 to on, power cycle brd then it boots correctly.
I am no expert with the SDK/Vitis tools so am sure I am doing something obviously incorrect. Can you please help me out.
Thanks!
#78
Trenz Electronic FPGA Modules / Re: TEB0835 Fan Ctrl via LM961...
Last post by StefanK82 - September 13, 2024, 10:06:35 AMMorning everybody,
I solved yesterday's problem myself. My mistake was to rely on the fan's data sheet and take the yellow wire as the PWM signal. This is correct for the fan. But the pinning of the TEB0835 does not reflect this. Long story short, it's just a pinning issue. The pins of the TEB0835 and the KK0835-02 cooling kit do not match. Just swap the blue/yellow cable assignment and everything works like a charm.
Have fun
Stefan
I solved yesterday's problem myself. My mistake was to rely on the fan's data sheet and take the yellow wire as the PWM signal. This is correct for the fan. But the pinning of the TEB0835 does not reflect this. Long story short, it's just a pinning issue. The pins of the TEB0835 and the KK0835-02 cooling kit do not match. Just swap the blue/yellow cable assignment and everything works like a charm.
Have fun
Stefan
#79
CYC1000 community projects / Re: How to flash Nios code to ...
Last post by rewvas - September 13, 2024, 04:06:15 AMQuoteSo far I've managed to flash sof files to EPC flash by creating the jic file.
But now I also want the elf file (generated by Nios gcc) also to be flashed into EPC flash.
Using Nios Programmer failes due to bug in sof2flash since 17.1 (related to cyclone 10)
There must be also other way:
I assume I've to add the hex file (converted from elf) to the "Convert Programming Files" tool.
Unfortunately the address where this hex file is placed seems to be wrong. The Nios application is not starting.
I'm basically using the provided Quartus design but added small Nios application.
Starting and debugging Nios application directly via Jtag works, so application itself is correct.
It sounds like you're trying to flash both the SOF file (for the FPGA configuration) and the ELF file (for the Nios II processor application) into EPC flash but encountering issues with the Nios Programmer due to a bug in the sof2flash utility since Quartus version 17.1.
You are correct that you need to convert the ELF file to a HEX file for inclusion in the "Convert Programming Files" tool. You can use the elf2hex tool that comes with Nios II to generate a HEX file from the ELF file. The command looks like this:
Code Select
elf2hex --input=application.elf --output=application.hex --base=0x800000 --end=0x810000
Make sure the base address matches where your Nios II processor expects the application to be loaded in memory. You can find this address in the Nios II BSP settings (in the linker script or memory map). #80
Trenz Electronic FPGA Modules / TEB0835 Fan Ctrl via LM96163 (...
Last post by StefanK82 - September 12, 2024, 03:28:46 PMHello everyone,
It's not a major issue for my project but I have a problem with my TEB0835 base board and hope someone can show me my mistake.
The speed of the cooling fan should be controlled by U9 (LM96163, compatible with LM63), which reads the temperature and provides a PWM output for fan control.
My headache is that the level (pwm frequency) on the PWM pin (U9-5) cannot be influenced by anything.
According to the LM96163 data sheet, the PWM output is an "open-drain digital output", whereby GND level should be applied by default in the POR state.
Nevertheless, I can measure a permanent output voltage of about 11.4 volts at pin J21-4, even in the POR state of the not configured LM96. The only way to reduce this is to reduce the Boards input voltage.
I perform the configuration of the LM96 during the uboot with the "PRE_BOOT" variable and the register set shown in the following. The order of the registers is specified in the data sheet as the prescribed order and also reflects the configuration order.
(Line breaks and comments are only made for a readability and do not reflect to PRE_BOOT variable content)
CONFIG_PREBOOT="
i2c dev 4;
i2c md 0x4c 0x33; # Check device came up w/o error
i2c mw 0x4c 0x30 0x00; # Disable TrueTherm Diode
i2c mw 0x4c 0x4a 0x20; # Set PWM WR_EN / trad. TACH input
i2c mw 0x4c 0x4b 0x0f; # Use DCyc and SpinUp Time for SpinUp
i2c mw 0x4c 0x4d 0x08; # Select a PWM OutFreq of 22.5 kHz
i2c mw 0x4c 0x4e 0x00; # LUT TempOffset (0°C)
i2c mw 0x4c 0x4f 0x08; # LUT Hyst. (20°C(?))
i2c mw 0x4c 0x50 0x15; # LUT Temp 1 (21°C)
i2c mw 0x4c 0x51 0x13; # LUT PWM 1 (30% DCYCLE) (FAN Minimum)
i2c mw 0x4c 0x52 0x29; # LUT Temp 2 (41°C)
i2c mw 0x4c 0x53 0x16; # LUT PWM 2 (35% DTY CYCLE)
i2c mw 0x4c 0x54 0x31; # LUT Temp 3 (49°C)
i2c mw 0x4c 0x55 0x1A; # LUT PWM 3 (40% DTY CYCLE)
i2c mw 0x4c 0x56 0x39; # LUT Temp 4 (57°C)
i2c mw 0x4c 0x57 0x1D; # LUT PWM 4 (45% DTY CYCLE)
i2c mw 0x4c 0x58 0x41; # LUT Temp 5 (65°C)
i2c mw 0x4c 0x59 0x20; # LUT PWM 5 (50% DTY CYCLE)
i2c mw 0x4c 0x5A 0x49; # LUT Temp 6 (73°C)
i2c mw 0x4c 0x5B 0x48; # LUT PWM 6 (75% DTY CYCLE)
i2c mw 0x4c 0x5C 0x51; # LUT Temp 7 (81°C)
i2c mw 0x4c 0x5D 0x3F; # LUT PWM 7 (85% DTY CYCLE)
i2c mw 0x4c 0x5E 0x59; # LUT Temp 8 (89°C)
i2c mw 0x4c 0x5F 0x3F; # LUT PWM 8 (95% DTY CYCLE)
i2c mw 0x4c 0x60 0x61; # LUT Temp 9 (97°C)
i2c mw 0x4c 0x61 0x3F; # LUT PWM 9 (100% DTY CYCLE)
i2c mw 0x4c 0x62 0x69; # LUT Temp 10 (105°C)
i2c mw 0x4c 0x63 0x3F; # LUT PWM 10 (100% DTY CYCLE)
i2c mw 0x4c 0x64 0x71; # LUT Temp 11 (113°C)
i2c mw 0x4c 0x65 0x3F; # LUT PWM 11 (100% DTY CYCLE)
i2c mw 0x4c 0x66 0x71; # LUT Temp 12 (121°C)
i2c mw 0x4c 0x67 0x3F; # LUT PWM 12 (100% DTY CYCLE)
i2c mw 0x4c 0x4e 0x00; # LUT Temp Offset (0°C)
i2c mw 0x4c 0x45 0x00; # Enh. Config (Default)
i2c mw 0x4c 0x4a 0x03; # Reset PWM WR_EN
i2c mw 0x4c 0x03 0x85; # Mask ALERT INTR / En TACH / Filter Remote Diode
i2c mw 0x4c 0xBF 0x05" # RD Filter LVL 2 / selfclear ALERT
I checked register setup and PWM output reg by unloading the LM63 kernel module and reading the register content directly via 'i2cget'.
I checked positive, that the PWM output register 0x4C takes over the correct values from the LUT according to the given temp.
Only the output pin, measured with an oscilloscope, shows no change or PWM-like signal anyway.
Is there a known hardware related problem with it or anyone has an idea what I am doing wrong?
Thanks in advance for any valuable advice!
CU
Stefan
It's not a major issue for my project but I have a problem with my TEB0835 base board and hope someone can show me my mistake.
The speed of the cooling fan should be controlled by U9 (LM96163, compatible with LM63), which reads the temperature and provides a PWM output for fan control.
My headache is that the level (pwm frequency) on the PWM pin (U9-5) cannot be influenced by anything.
According to the LM96163 data sheet, the PWM output is an "open-drain digital output", whereby GND level should be applied by default in the POR state.
Nevertheless, I can measure a permanent output voltage of about 11.4 volts at pin J21-4, even in the POR state of the not configured LM96. The only way to reduce this is to reduce the Boards input voltage.
I perform the configuration of the LM96 during the uboot with the "PRE_BOOT" variable and the register set shown in the following. The order of the registers is specified in the data sheet as the prescribed order and also reflects the configuration order.
(Line breaks and comments are only made for a readability and do not reflect to PRE_BOOT variable content)
CONFIG_PREBOOT="
i2c dev 4;
i2c md 0x4c 0x33; # Check device came up w/o error
i2c mw 0x4c 0x30 0x00; # Disable TrueTherm Diode
i2c mw 0x4c 0x4a 0x20; # Set PWM WR_EN / trad. TACH input
i2c mw 0x4c 0x4b 0x0f; # Use DCyc and SpinUp Time for SpinUp
i2c mw 0x4c 0x4d 0x08; # Select a PWM OutFreq of 22.5 kHz
i2c mw 0x4c 0x4e 0x00; # LUT TempOffset (0°C)
i2c mw 0x4c 0x4f 0x08; # LUT Hyst. (20°C(?))
i2c mw 0x4c 0x50 0x15; # LUT Temp 1 (21°C)
i2c mw 0x4c 0x51 0x13; # LUT PWM 1 (30% DCYCLE) (FAN Minimum)
i2c mw 0x4c 0x52 0x29; # LUT Temp 2 (41°C)
i2c mw 0x4c 0x53 0x16; # LUT PWM 2 (35% DTY CYCLE)
i2c mw 0x4c 0x54 0x31; # LUT Temp 3 (49°C)
i2c mw 0x4c 0x55 0x1A; # LUT PWM 3 (40% DTY CYCLE)
i2c mw 0x4c 0x56 0x39; # LUT Temp 4 (57°C)
i2c mw 0x4c 0x57 0x1D; # LUT PWM 4 (45% DTY CYCLE)
i2c mw 0x4c 0x58 0x41; # LUT Temp 5 (65°C)
i2c mw 0x4c 0x59 0x20; # LUT PWM 5 (50% DTY CYCLE)
i2c mw 0x4c 0x5A 0x49; # LUT Temp 6 (73°C)
i2c mw 0x4c 0x5B 0x48; # LUT PWM 6 (75% DTY CYCLE)
i2c mw 0x4c 0x5C 0x51; # LUT Temp 7 (81°C)
i2c mw 0x4c 0x5D 0x3F; # LUT PWM 7 (85% DTY CYCLE)
i2c mw 0x4c 0x5E 0x59; # LUT Temp 8 (89°C)
i2c mw 0x4c 0x5F 0x3F; # LUT PWM 8 (95% DTY CYCLE)
i2c mw 0x4c 0x60 0x61; # LUT Temp 9 (97°C)
i2c mw 0x4c 0x61 0x3F; # LUT PWM 9 (100% DTY CYCLE)
i2c mw 0x4c 0x62 0x69; # LUT Temp 10 (105°C)
i2c mw 0x4c 0x63 0x3F; # LUT PWM 10 (100% DTY CYCLE)
i2c mw 0x4c 0x64 0x71; # LUT Temp 11 (113°C)
i2c mw 0x4c 0x65 0x3F; # LUT PWM 11 (100% DTY CYCLE)
i2c mw 0x4c 0x66 0x71; # LUT Temp 12 (121°C)
i2c mw 0x4c 0x67 0x3F; # LUT PWM 12 (100% DTY CYCLE)
i2c mw 0x4c 0x4e 0x00; # LUT Temp Offset (0°C)
i2c mw 0x4c 0x45 0x00; # Enh. Config (Default)
i2c mw 0x4c 0x4a 0x03; # Reset PWM WR_EN
i2c mw 0x4c 0x03 0x85; # Mask ALERT INTR / En TACH / Filter Remote Diode
i2c mw 0x4c 0xBF 0x05" # RD Filter LVL 2 / selfclear ALERT
I checked register setup and PWM output reg by unloading the LM63 kernel module and reading the register content directly via 'i2cget'.
I checked positive, that the PWM output register 0x4C takes over the correct values from the LUT according to the given temp.
Only the output pin, measured with an oscilloscope, shows no change or PWM-like signal anyway.
Is there a known hardware related problem with it or anyone has an idea what I am doing wrong?
Thanks in advance for any valuable advice!
CU
Stefan