malexander
-
Posts
224 -
Joined
-
Last visited
Content Type
Profiles
Forums
Events
Gallery
Posts posted by malexander
-
-
I looked back at the changes that were made between 2.17.1 and 2.18.3:
Adept Runtime for Linux 2.18.3 (07/13/2018):
1. Updated FTDI driver to version 1.4.8.Adept Runtime for Linux 2.18.2 (06/22/2018):
1. Added support for FTDI FWID 0x61, which is used by a future product.Adept Runtime for Linux 2.18.1 (06/14/2018):
1. Added support for FTDI FWID 0x58, which is used by the Zuca.
2. Added support for FTDI FWID 0x59, which is used by the OpenLogger MZ.Adept Runtime for Linux 2.17.1 (12/15/2017):
1. Added the ability to configure the XC7S25, XC7S50, and XCZ007S.
2. Extended the DSTM API set to include the following functions:
DstmTransferI suspect that the issue may be related to the FTDI driver (libftd2xx.so). You could try downloading the tar.gz for Adept Runtime 2.17.1 that matches your platform and use the FTDI driver from that version to replace the library installed on your system. If that resolves the issue then we know it's being caused by something FTDI changed in their driver.
Thanks,
Michael -
Hi @JerryM
Is there anything on your network that would block UDP broadcast or MDNS-SD? We use those two mechanisms to discover network devices during enumeration when the host is Linux or MAC and the ADP3450 is running Linux. Windows hosts can also support MDNS-SD but it's not enabled because we didn't build the dependencies into the installer. I don't think the ADP3450 standard mode (non-Linux) supports MDNS-SD, and in that case, discovery is performed entirely with UDP broadcast. You could try running Linux mode on the ADP3450 and see if it makes any difference - just please be sure to use the latest image, as older images may not support on features of Adept.
Thanks,
Michael -
I don't have any experience running our software in a VDI setup but have successfully used it with VMWare and VirtualBox, where the VM is hosted on the local hardware. I quickly skimmed a description of how VDI works and was given the impression that it involves one or more servers hosting the virtual machine with clients connecting remotely with through a local client running on their own hardware. Is this correct? Is the Analog Discovery connected to the server running the VM, or is it connected to a local desktop / think client that remotely connects to a server hosting the VM?
Maybe the UDEV rules are being applied correctly. If that's the case RW permission may not be assigned to the files created for the USB device. Have you tried running the software with "sudo" to see if that makes any difference?
Thanks,
Michael -
@JerryM Adept Runtime 2.19.2 was released in October of 2018. The first internal release of the Adept Runtime to support Ethernet is 2.21.0, which was released in August of 2020. Many feature enhancements and bugfixes were made between then and August 2021, when version 2.26.1 was released. If you want network connectivity to work reliably then you need to install Adept Runtime 2.26.1 or newer.
Thanks,
Michael
Adept Runtime for Linux 2.26.1 (08/05/2021):
1. Fixed a bug that caused device table entries whose hostname couldn't be
resolved not to be returned in the list of enumerated devices.
2. Defined error codes ercNameResolutionFailed, ercHostUnreachable,
ercConnectionTimeout, and ercAuthenticationFailed and modified several
internal routines so that a more appropriate error code would be set when
one of the account management, SetInfo, or GetInfo calls fails.
3. Added the ability to override the global enable/disable TLS setting by
appending ":ENABLE_TLS" or ":DISABLE_TLS" to the end of a TCPIP
connection string.
4. Added support for the Digital Discovery to use VID=0x1443 and PID=0x7004.Adept Runtime for Linux 2.25.1 (07/20/2021):
1. Removed the requirement for a connection to be secured with TLS when
sending credentials to a device. The connection will be encrypted with
TLS if the device supports it, but TLS is no longer required. At the time
of this release only the Analog Discovery Pro 3450 and Analog Discovery
Pro 3250 support TLS, and TLS only supported in Linux mode on those
devices.
2. Removed the requirement for a connection to be secured with TLS when
sending account management commands to a device. The connection will be
encrypted with TLS if the device supports TLS, but TLS is no longer
required for account management commands to be sent to the device. At the
time of this release only the Analog Discovery Pro 3450 and Analog
Discovery Pro 3250 support TLS, and TLS only supported in Linux mode on
those devices.Adept Runtime for Linux 2.24.1 (07/13/2021):
1. Extended the DMGR API set to include the following functions:
DmgrDvcTblClear
2. Changed the way that the device table is enumerated in order to fix a
bug that resulted in DVC/EDVC entries being created for device table
entries prior to device discovery being completed. This issue would only
show up when the DVC/EDVC entries were fetched immediately after being
created while performing a non-blocking enumeration. In order to fix this
bug it was necessary to require that all device table entries include
both the transport type (TPT) and communication protocol (PTC) in their
DTP field. Any device table entry that does not include both TPT and PTC
is ignored.
Existing device table entries will need to removed and recreated. If
Adept no longer sees your device table entries then it's likely that they
only included the transport type and not the protocol. Please download
the "Adept Utilities" package and execute "dadutil tblclr" to remove the
old entries. You can then create new entries using "dadutil tbladd".Adept Runtime for Linux 2.23.2 (07/09/2021):
1. Modified "install.h" to fix a bug that resulted in the UDEV rules not
being properly generated on CentOS 8.4.
2. Modified "install.h" to update the firewall rules to allow the mdns
service after discovering that the default firewall rules on some
non-debian distributions (CentOS and OpenSUSE) do not allow the mdns
service even though they ship with the service enabled.
3. Modfied RPM post install script to update the firewall rules when
necessary so that MDNS can be used for discovering network devices.Adept Runtime for Linux 2.23.1 (06/28/2021):
1. Added the ability to discover network devices using Multicast DNS
Service Discovery. Network devices that register the appropriate service
name will be discovered through MDNS-SD. Devices that do not support
MDNS-SD can still be discovered using UDP broadcast. This is 100%
transparent to the user.
2. Modified NENUMRESP to add support for V2 fields by reducing the size of
the "ver" field from 4 bytes to 2 bytes. The upper two bytes are now
set asside for compatible devices to return additional information known
as the "V2 fields". These additional fields include information about
client authentication, control channel TLS, and data channel TLS
3. Added "V2 fields" to the EDVC structure.
4. Fixed a bug that prevented DmgrStopEnum from stopping a non-blocking
enumeration that included network devices.
5. Made various bug fixes and improvements related to non-blocking
enumeration.
6. Switch from dynamic linking to static linking for OpenSSL to remove the
need to distribute shared libraries that may be in conflict with
libraries that were already installed on the system.
7. Add support for FTDI devices that use Digilent's USB Vendor ID.Adept Runtime for Linux 2.22.1 (05/03/2021):
1. Added support for encrypted network connections. Transport Layer
Security (TLS) is now enabled by default when communicating with
network devices that support TLS.
2. Added support for account management by extending the DMGR API set to
include the following functions:
DmgrIsClientAuthenticationEnabled
DmgrEnableDisableClientAuthentication
DmgrAddAccount, DmgrDeleteAccount
DmgrGetAccountAttributes
DmgrSetAccountAttributes
DmgrChangeAccountPassword
DmgrGetAccountList
3. Extended DMGR API set to include the following functions:
DmgrGetEdvc
DmgrEnableControlChannelTLS
DmgrEnableDataChannelTLS
DmgrIsControlChannelTLSEnabled
DmgrIsDataChannelTLSEnabled
DmgrIsControlChannelSecure
DmgrIsDataChannelSecureAdept Runtime for Linux 2.21.3 (03/31/2021):
1. Updated FTDI driver to version 1.4.22.Adept Runtime for Linux 2.21.2 (11/11/2020):
1. Fixed a bug that may have resulted in duplicate entries being created
for Ethernet devices in the list of enumerated devices.Adept Runtime for Linux 2.21.1 (09/30/2020):
1. Extended the DMGR API set to include the following functions:
DmgrSetNetworkEnumTimeout
DmgrGetNetworkEnumTimeout
DmgrSetNetworkConnTimeout
DmgrGetNetworkConnTimeoutAdept Runtime for Linux 2.21.0 (08/04/2020):
1. Added beta support for TCPIP connected devices (dtpEthernet).
-
Hi @JerryM
I think any version of the Adept Runtime that's older than 2.22.1 should work on CentOS 7. I'm not sure which, if any version of Waveforms will work with CentOS 7. That's a question @attila may be able to answer that question if you told us which version of glibc CentOS 7 includes. You can execute "yum list glibc" to see which version of the glibc package is installed.
Which WaveForms compatible devices are you trying to use?Older versions of the Adept Runtime can be downloaded here: https://digilent.com/reference/software/adept/runtime-previous-versions
Older versions of Waveforms can be downloaded here: https://digilent.com/reference/software/waveforms/waveforms-3/previous-versions
Thanks,
Michael -
Hi @Luoyong
As I mentioned previously, all versions of the HS2 are designed to work with VREF being between 1.8V and 5.0V.
If possible please use an oscilloscope to capture the TMS, TDI, TDO, and TCK signals at the JTAG header on your Kintex Ultrascale+ PCBA and post them here.
Thanks,
Michael -
Hi @Luoyong
Are you plugging the JTAG-HS2 directly into header J8 of the ZCU102 using the 14-pin adapter that comes with the HS2?
Is there any possibility that you have the onboard JTAG programmer open at the same time? This would create a drive conflict and prevent scan chain initialization from working. I'm curious, why are you using an external programmer/debugger on a board that has that capability integrated?
All versions of the JTAG-HS2 are designed to operate from 1.8V to 5.0V. It uses the same buffers as the JTAG-SMT2-NC that's loaded on the ZCU102. I reviewed the schematics and the only thing that stands out between HS2 and SMT2-NC is that the HS2 has 100 ohm resistors in series with the IO buffers, whereas the SMT2-NC does not but the ZCU102 does have 15 ohm series resistors between the SMT2-NC IO and the JTAG nets on the board. There's a potential for the increased series resistance to limit the maximum frequency, but I would expect communication to work at the lower clock frequencies if there are issues at higher frequencies.
The pull-up resistors were mentioned. With 4.7K pullups and a 100 ohm series resistor the HS2 will be able to drive a logic '0' to a minimum voltage of 0.0375V, which is well below the logic low threshold of the JTAG pins on processor bank 503 (0.63V max) so I don't think this is causing the issue.
Thanks,
Michael -
Hi @reddish
I've implemented a workaround in the Adept Runtime to address the issue you are experiencing with the Analog Discovery 2 and Digital Discovery. I tested the workaround with the desktop version of Waveforms and found that after hard killing a process that's connected to a device you can launch another copy of Waveforms and reconnect to the device. Waveforms still says that the device is in use because it looks at the open handle reference count, which is in shared memory and not updated when a process is hard killed, but you can now connect to the device again without the need to close all other processes referencing the Adept Runtime. This should also work with Waveforms SDK.
Please install Adept Runtime 2.27.6 using one of the packages below and let me know if this solves your issue.
Thanks,
Michael32-bit x86 Linux Debian Package
64-bit x86_64 Linux Debian Package
-
The expectation from the perspective of the Adept Runtime DLLs was always that the application using the APIs would call the appropriate functions to release resources once it is done with them. The DLLs/shared libraries use process attach and process detach (and GCC equivalent on other platforms) to perform some initialization and cleanup but they don't register signal handlers since that's typically done at the application level, and not inside of a library. An application can register the appropriate signal handlers and call the disable and close functions, which does avoid this problem. We should be able to do that in Waveforms and so should 3rd party applications using the SDKs, at least those written in C/C++.I was able to replicate the issue you are describing in Windows by connecting two Analog Discovery 2 devices, opening each one in Waveforms, and then using task manager to kill one instance of Waveforms.
Since multiple processes need to be able to access the device there is a variable in shared memory (protected by mutex) that keeps track of which interfaces are enabled, and is used to check for a conflict when a thread/process attempts to enable an interface on a handle. When Adept receives a request to enable a port it checks for a conflict, and if there is no conflict it will set a bit indicating which resource was enabled and allow the rest of the port initialization code to execute. When an application is done with an interface it's expected to call the associated disable function and then close the interface handle. When Adept processes such request it clears the bit in the variable that keeps track of the in use resource for the device. The variable in shared memory segment is only initialized the first time the DLL is loaded into RAM and in the scenario that this issue occurs the DLL remains loaded into RAM because there is still an application accessing the other device.
In actuality there two are locking mechanism. The one I described above, which is the original locking mechanism, and secondary locking mechanism that was later added for applications that access the device without the Adept API's but must share access to the hardware. The secondary locking mechanism also involves storing data structures in shared memory, but is different in that each device interface has it's own mutex associated with it and when an application wants access to the interface it must lock the mutex corresponding to that interface. In this case the mutex can be recovered if the application is terminated. Adept also uses this mechanism after it performs the original conflict check so a potential workaround could involve skipping the original conflict check.
I have confirmed that removing the call that checks to see if there is a resource conflict when enabling the interface and then relying on the secondary (newer) mechanism to prevent another process from accessing an in use resource works in the Adept test suite and that the resource lock can be recovered if owning thread was killed. However, I still see Waveforms listing the device as in use by another process and will need to discuss this with the developer. Further, there are other resources in shared memory that aren't getting cleaned up when you kill the process without calling the appropriate disable or close functions and it's not immediately obvious to me what impact that may have. I'm also hesitant to remove the original resource conflict check because at the time that the secondary locking mechanism was added (late 2013) there was at least one 3rd party developer who (against my recommendation) was distributing the shared libraries alongside their executable so that they could load a specific version of the Runtime libraries, instead of using the same version system wide, which is how the system was designed be used. There's no way for me to know how many 3rd party developers might be including old versions of Adept Runtime DLLs alongside their application and loading those instead of the version of the DLLs that are in the system location so there's some risk that making this change would cause unexpected problems for other developers.
You asked about timeline. If we were to make this change, and if it only involved making the changes I already tried, then the majority of the time would be spent on testing with different hardware and software combinations across multiple platforms. I imagine that might take a day or two, depending on how thorough the testing is. However, that doesn't mean this will get done immediately because it involves diverting resources from other projects. We will discuss this internally to determine the full impact of the change and a timeline for when it will be implemented if we do make the change.
-
I would like to fix this issue but got busy with other things and haven't taken the time to dig into it. I quickly glanced at the code again after re-reading the problem description I suspect that this same issue may also be present in Windows. It's not clear to me that there's a way to address this inside of the DLL without re-writing a significant amount of code. I will look at this some more next week and try to remember why there is a single shared table that contains the conflict masks for all devices, rather than separate shared memory segments for each individual device.
-
1 hour ago, zygot said:
Gee... sometimes trying to explain things just makes the situation more confusing. So... what you're saying is that there isn't any good reason for all of those missing schematic pages for your hardware because the schematic doesn't have anything to do with Digilent's Intellectual Property given that the configuration information has never been part of the schematics?
I'm not trying to cause confusion, but rather point out that having the missing page may not allow Endres to achieve the desired goal. Not publishing portions of some schematics, or in the other cases withholding entire schematics, is a business decision. Individuals that want access to missing pages or schematics can request them and in some cases Digilent may provide unpublished pages or schematics.
-
@Endres Having access to the schematic will help you replicate the circuitry but it won't allow Vivado / Vitis to see the device. For that, the device must be programmed with a special configuration, which we consider IP that we may license to third parties.
-
I found some Microsoft FAQ's about running software on ARM platform. Support for applications in Windows 10 requires that they be compiled for 64-bit (ARM64), 32-bit (ARM32), or 32-bit (x86). The Windows 11 FAQ does not explicitly mention processor architectures which suggests that it can run both 32-bit and 64-bit applications regardless of if they are compiled for Intel or ARM. Both Windows 10 and 11 require ARM drivers for any hardware that an application communicates with.
The FAQ can be found here: https://support.microsoft.com/en-us/windows/windows-arm-based-pcs-faq-477f51df-2e3b-f68f-31b0-06f5e4f8ebb5#ID0EFD=Windows_11
I sent an email to FTDI to get a complete list of the operating systems / architectures supported by driver 2.12.36.4U and to ask for reseller rights so that we can include that driver in our installer.
Support for ARM devices running Windows isn't on our roadmap so I don't have an ETA for when Analog Discovery Pro or other upcoming devices will be supported. There's also no ETA for an ARM version of the Adept Runtime for Windows. I will also marketing to do some research on the demand for this platform.
Thanks,
Michael -
I upgraded to 12.1 and the Analog Discovery II is still working with Waveforms when connected through the USB C to Micro B cable or when connected through a USB A to Micro B cable plugged into the U Green hub. Please upgrade to OS 12.1 and see if the problem persists.
Thanks,
Michael -
Unfortunately, I don't have that version of OSX installed anymore. The MacBook pro is on 11.4 and I just upgraded the M1 based MAC Mini to 12.1 to work through a different support question. I'm not sure how to install it natively... there's no optical drive on the MBP and I don't have the disc image. Maybe we can run it in VM?
-
I received both the cable and the USB-C hub. Waveforms has no issue detecting and communicating with the Analog Discovery II when it's connected through the USB C to Micro B cable or when it's connected through a USB A to Micro B cable plugged into the U Green hub on the 2020 M1 Mac Mini that's running Mac OS 11.6.1. I will upgrade it to 12.1 and see if it still works. Have you tried updating to 12.1?
Thanks,
Michael -
I don't have a USB-C to Micro B cable but they do seem to exist: https://www.amazon.com/Cable-Matters-Micro-Braided-Jacket/dp/B00UUBRX0Y/ref=asc_df_B00UUBRX0Y/?tag=hyprod-20&linkCode=df0&hvadid=309818716690&hvpos=&hvnetw=g&hvrand=18000274225735162518&hvpone=&hvptwo=&hvqmt=&hvdev=c&hvdvcmdl=&hvlocint=&hvlocphy=9033767&hvtargid=pla-475484999927&psc=1
I ordered the cable and the USB-C hub from Amazon to try with the 2020 M1 MacMini. Apparently Prime shipping is really slow these days... estimated arrival is Saturday the 8th. I'll try to look at this early next week.
Thanks,
Michael -
Just to confirm, have you tried connecting the AD2 directly to your 2020 M1 MacBook Pro without the hub to see if that makes any difference?
Can you provide the full part number for the UGREEN USB-C hub? I don't have a M1 MacBook Pro but I do have a 2021 M1 MacMini that I could try to replicate this with.
Thanks,
Michael -
It's my understanding that Vivado/Vitis/SDK drive PS_POR and PS_SRST automatically as needed. However, it is possible to drive them manually. It's been quite a long time since I last did this but here are the instructions that I was given by Xilinx:
1. Start XSDB
2. source jtagpins.tcl
3. connect
4. Set tag target to the cable you want to test, e.g. “jtag target 1”
5. To assert reset do: "setpin SRST 0” or “setpin POR 0”
6. To de-assert reset do: "setpin SRST 1” or “setpin POR 1"I don't recall what the name of the target is and I don't have the hardware here so I can't try it out, sorry.
-
I'm glad you got it working Happy holidays!
-
As far as I know 2020.1 should work but you could try upgrading to a newer version.
Have you checked to see if the Adept GUI application can see the JTAG_SMT4?
Thanks,
Michael -
Which version of Vivado are you using? As I recall 2020.1 is the oldest release that supports the JTAG-SMT4.
Thanks,
Michael -
Breadboard's add a lot of capacitance so that's probably why it doesn't work. Hopefully, it will work with your cable solution, but this is not how the module was intended to be used.
-
The screenshots you sent me don't indicate a driver problem, but rather what is likely a USB signal integrity issue. Have you tried using a different USB cable, or plugging it into a different port? What about a different Windows 10 PC? When you say you attached this to your existing board - is that a board that has SMT pads for the JTAG-SMT4 that follow the land pattern guidelines provided in the reference material? Have you added any additional series resistors or ESD diodes to USB D+/D-?
Using Waveforms to connect to Analogue Discovery 2 on an Ubuntu VDI image
in Test and Measurement
Posted
HI @Jeremy LAURENT
Interesting. I wonder if it's all versions > 1.0.4 or just some of them. The release notes imply that there were a lot of releases between 1.0.4 and 1.4.24. We didn't test them all... only the ones we included in the installer. If you can find an old download link you might try some of the newer ones and see if it makes any difference. I think it's also worth trying the latest (1.4.27) to see if that resolves the issue. Please share any additional information you discover here.
https://ftdichip.com/drivers/d2xx-drivers/
https://ftdichip.com/wp-content/uploads/2022/07/release-notes.txt
https://ftdichip.com/wp-content/uploads/2022/07/libftd2xx-x86_64-1.4.27.tgz
Thanks,
Michael