Jump to content

malexander

Technical Forum Moderator
  • Posts

    217
  • Joined

  • Last visited

About malexander

Profile Information

  • Gender
    Female

Recent Profile Visitors

3,806 profile views

malexander's Achievements

  1. malexander

    __strcmp_sse42

    @perdue This is not a known issue - we have linked our own libraries and applications against 2.27.9 and they run without issue. I'm curious to here if you also experience this problem with 2.22.1, as that is the earliest release that includes SSL/TLS support for the ADP3xxx series. Below are links for the desktop installers: https://digilent.s3.us-west-2.amazonaws.com/Software/Adept2+Runtime/2.22.1/digilent.adept.runtime_2.22.1-amd64.deb https://digilent.s3.us-west-2.amazonaws.com/Software/Adept2+Runtime/2.22.1/digilent.adept.runtime_2.22.1-i386.deb https://digilent.s3.us-west-2.amazonaws.com/Software/Adept2+Runtime/2.22.1/digilent.adept.runtime-2.22.1.x86_64.rpm https://digilent.s3.us-west-2.amazonaws.com/Software/Adept2+Runtime/2.22.1/digilent.adept.runtime-2.22.1.i686.rpm https://digilent.s3.us-west-2.amazonaws.com/Software/Adept2+System+Installer/2.22.1/digilent.adept.system_v2.22.1.exe The Adept SDK (includes lib files for linking in Windows) hasn't been published since 2016 since the public API hasn't changed. Can you please tell me which distribution of Linux you are using? Thanks, Michael
  2. @aminoh I was having trouble getting OpenSUSE to work in VMWare so I was unable to verify that the error goes away. However, I have signed and re-uploaded all of the RPM and DEB packages for the Adept Runtime and Adept Utilities to our website. You will need to import our public GPG key, which I've attached here. Hopefully, that key will be published on our website soon. Thanks, Michael digilent_public_key.asc
  3. @aminoh I briefly looked into this and resolving this issue seems fairly straight forward. I believe we just need to generate a GPG key, sign the package, and publish our public key on our website so that users can import it. Which version of OpenSUSE are you running? I'd like to spin it up in a VM verify the process. Thanks, Michael
  4. @GLC The Cora Z7 has a dual channel USB controller attached to the USB MicroB connector next to power jack. Channel A is used for JTAG and Channel B is UART. You should see multiple devices in the device manager similar to the image I've attached. There should be two entries for the device shown under the "Universal Serial Bus controllers" section and a single entry under "Ports (COM& LPT)". Can you please check to see if you have similar entries in the device manager on your system? Are there any unknown devices? Thanks, Michael
  5. Hi Kishore, This is outside my field of expertise, as I wrote decutil and gave the source code to a colleague back in 2019 to integrate into our Petalinux image. I sent an email to someone who has more expertise in this and asked him to help answer your questions. It's already after-hours where he is located so it may be a day or two before he responds. Thanks, Michael
  6. Hi Kishore, I'm sorry but the PMCU firmware on the Eclypse Z7 is Digilent IP that I'm unable to share. One of our former employees took my decutil code and added a hardware abstraction layer to allow most of the code to function in both baremetal and Linux. It was then renamed to dpmutil and published on our github and you can find the code here. Can you try cloning that repository and building the application in whichever version of Petalinux you are using and see if it works? If it builds and runs but has an error finding or opening the I2C device then you might try one of the following: 1. Run it with sudo or switch to root with su and then run it. 2. Look at function I2CHALOpenI2cController in I2CHAL.c. It searches sysfs for an I2C device with name "pmcu-i2c" and if it finds one then it will open that device. Otherwise, it will attempt to open "/dev/i2c-0". It's possible that something changed with the sysfs directory struct since decutil was published and that might cause the I2C device not to be found. You can change variables szI2cDeviceName and szI2cDeviceNameDefault which are defined at lines 38 and 39 of I2CHAL or modify I2CHALOpenI2cController to skip the search entirely and just open the device using the path defined by szI2cDeviceNameDefault and then recompile the application. As far as I can remember we didn't do anything special in the device tree, other than associate "pmcu-i2c" with I2C0 of the Zynq PS. To answer your question, yes I'm convinced that this is some sort of software issue and integrating dpmutil (previously decutil) will allow you to communicate with the platform MCU from Linux to turn on the power supplies. That being said, none of this should even be necessary, as the SYZYGY specification expects anything you plug into a SYZYGY port to contain an MCU with the DNA for the module and contain the voltage ranges the module supports. If you program a valid DNA into the module then the power will turn on automatically and you shouldn't need to interact with the platform MCU at all. Thanks, Michael
  7. Hi Kishore, I) Register 0x804C is read only and should only contain the target voltage so if it's non-zero then that suggests that the value came from reading the SYZYGY DNA (if it exists) or from writing to the override register. The value (0xC0B4) you specify for register 0x804E seems correct to me for overriding and enabling VADJA at 1.8V. I'm not sure why you read it back as 0 but one possibility is that there's a timing issue. I'm not familiar with the i2ctransfer application. One thing you might try is writing a custom application. I've attached the source code for the functions that are used by decutil to read and write the Platform MCU registers. Please note that there does appear to be a delay between reads. It would be really helpful to know if decutil from our linux image works with our Linux image running when nothing is plugged in. That might tell us if this is a software or a hardware problem. If decutil is able to override and turn on the supplies then we know this is a software issue. 2^10 is 1024 so the maximum override voltage could be 10.23V. A value of 0xB4 corresponds to 180 and since it's in 10mV increments that gives you 1.8V so I don't see an issue there. No changes are required to the platform configuration or reset registers. II) What do you mean by "get complete firmware on PMCU"? III) Yes, there is a difference between no DNA being present and nothing being connected to the ZMOD. Consider the following scenarios: 1. There is no board plugged into the ZMOD A port. This means that there isn't an MCU to ACK SLA+W from the PMCU so the PMCU will not think a module is present. In such case, you can use VADJ_n_OVERRIDE to set the voltage to anything within the valid range (I think its 1.2V to 3.6V on this board). 2. There is a board plugged into the ZMOD A port. The following scenarios are possible: a. There is no MCU on the board and no other device on the board to respond to SLA+W. Therefore the PMCU thinks that no module is present and will allow override. b. There is an MCU on the board but it doesn't respond to SLA+W. This is the same as scenario 2a and override will be allowed. c. There is an MCU on the board and it responds to SLA+W but the DNA is empty or invalid due to CRC mismatch. The PMCU will think there is a module present and consider it unsafe to allow the VADJ supply to turn on because it can't determine if the requested voltage will damage the hardware. This is a safety mechanism and override will not be allowed. We did not build in any mechanism for disabling this safety feature. If you want to get around it while doing hardware development you could consider cutting the I2C traces on your board until you are ready to include proper DNA and then reconnect them. d. There is an MCU on the board and it responds to SLA+W and the DNA is valid. Override will be allowed but the voltage will be limited to the range(s) specified in the DNA. In such case make sure your DNA contains one or more range with the voltage that you want to set or just set it to 1800mV min and max and the supply will just turn on automatically at 1.8V as desired (SmartVIO). Please try decutil with our Linux image and no boards plugged in to help us determine if this is a hardware or software issue. Thanks, Michael PlatformMCU.c
  8. Hi Kishore, My colleague @artvvb loaded image 0.3 onto an SD card, booted the Eclypse Z7 without anything plugged into Zmod A or B, and confirmed that he was able to set the voltage to 1.8V and then 3.3V using the decutil setviocfg command. He measured voltages of 1.821V and 3.327V. Please download the v0.3 image here and then follow Step 2 of the "Setting up the Linux Projects" section described here to get our petalinux image up and running. Once you've booted please execute "sudo decutil setviocfg -chanid a -override y -enable y -voltage 1800" to set enable VADJA and set the voltage to 1.8V. If you want to do the same for VAJDB then you can execute "sudo decutil setviocfg -chanid b -override y -enable y -voltage 1800". Please let me know if this works, and again, make sure you have no boards or cables connected to ZMOD A or ZMOD B. Thanks, Michael
  9. @Quello I'm sorry that no one figured this out sooner but we were just looking at this again for a question asked by a different customer and I stumbled upon this thread. The reason it's saying it failed to open the I2C file is because the permissions for that file require root to access it. Please use sudo to run the command or use su to switch to root and then run the command. Thanks, Michael
  10. Hi Kishore, I don't see anything contradiction in my statement. If your "other board" has an MCU that has its I2C lines connected to the SYZYGY I2C lines and the MCU on your "other board" responds to SLA+W from the Eclypse platform MCU then the firmware will consider a pod present. In such case it will attempt to read the DNA and compute the CRC. If the DNA is valid then it will take the min and max voltage from the DNA. If no DNA is present, or it is corrupt, then the min and max voltage are set to 0V and you won't be able to use the override register to enable the supply. If the Eclypse platform MCU does not detect anything on the I2C lines then it will not consider a module present, and I believe it will then let you override the voltage settings and enable the supply. You should also be able to override the voltage when a valid DNA Is present, but the min and max voltage that you can specify is limited to voltage ranges specified in the DNA. One thing I suggest trying is downloading our base Linux image and using the decutil / dpmutil (I think it was renamed to dpmutil for the final image but it was originally called decutil) to enable and override the voltage setting. Please do this without anything plugged into the ZMOD A or B ports. If this works then you will see LD3 and/or LD2 illuminate, depending on which supply you enable. I would try this myself but I'm unable to locate my SD card reader/write and cannot load the base image onto an SD card. As a result, I asked a colleague to try this and he has agreed to do so, but said he may not get to it today. There are a couple of different ways to overwrite the MCU firmware. 1. Use an MPLAB SNAP Debugger to program firmware directly via header J9 (see attached image for location and signal names). Please note that J9 is accessible from the bottom of the board underneath PMOD A. The pin spacing is 0.1". 2. Write a Linux application that programs the MCU using SPI via the MCU_MISO, MCU_SCK, MCU_NRESET, and MCU_MOSI nets that are connected to bank 35 of the PL. I believe this is how the manufacturing test writes the MCU, using a custom application that's not included in the Eclypse Z7 base Linux image. We may be able to provide you with the source code for this application (Possibly requiring NDA), but I can't promise that it will work in newer versions of Petalinux, as it was written by a former employee and was last updated in August of 2019. Thanks, Michael
  11. Are you using Linux or Baremetal? I looked through the firmware and it appears that the SYZYGY_A_DET and SYZYGY_B_DET nets will only be driven to logic '1' if a pod is detected in the associated port and associated power good signal (PGVADJA, PGVADJB, PGVADJC) coming from IC25 or IC27 is logic '1'. It appears that when the platform MCU firmware starts up it detects the presence of a pod by placing a start condition followed by SLA+W on the I2C bus at the address for each pod. If it receives an ACK then the pod is marked as present for that port and the minimum and maximum allowed voltages for the port are defaulted to 0. It then attempts to read the SYZYGY DNA and if present it will update the variables that are storing the min and maximum voltage allowed for the associated port. When the override command is received the firmware forces the specified voltage to be within the range previous determined for the min and max voltage. What this means is that if you have a pod with an MCU that responds to SLA+W but does not return a valid SYZYGY DNA, then you won't be able to override the voltage on that port. This is a safety check to prevent users from accidentally damaging their pods. I believe you should be able to force start the VIO supply at any voltage you want if no pod is present. Do you have a pod plugged into the port whose VIO supply you are trying to enable? If so, does it have an MCU connected to the I2C bus, and if so, will it respond to SLA+W? If yes, is their a valid DNA that can be read back over I2C? Thanks, Michael
  12. To the best of my recollection you need to write the VADJ_n_OVERRIDE register and set the fOverride bit to 1, set fEnable to 1, and set vltgSet10mV field to the voltage you want (in 10mV increments). This is described in section 6 of the Platform MCU Specification and the source code for the decutil application appears to write this register to enable the supply and set the voltage. Please note that you won't be able to set a voltage that would conflict with the requirements specified in the DNA of any module plugged into the port, or the requirements of the adjacent port if it's a double wide module. If the SYZYGY DNA of the module is blank they you should able to set any voltage that you want that meets the specifications for the supply. I've attached a snippet from the decutil source code that shows the sequence of operations it takes to override the voltage. Hopefully this helps you get it working. Thanks, Michael main.c PlatformMCU.h
  13. @attila I think there is the possibility of a race condition between line 591 of dvtopn.cpp and line 1991 of dvt.cpp in a scenario where the transfer thread gets out of sync because DVT::Disconnect logs an error message when synchronization fails but then continues on with the cleanup process which could cause the shared memory storing the named mutex to be destroyed. Perhaps terminating the transfer thread in such a scenario would avoid the crash. Of course, this is just speculation because unless I can replicate the behavior in the debugger there's no way for me to know with certainty that this is what caused the crash. @Wayne Contello Can you tell me if you are able to reproduce this behavior, and if so, what steps you are taking and what hardware you are using?
  14. @Mats1848 I don't see any obvious issues with the information you've entered and underscore characters are valid in an alias. I'm guessing the device table file has been corrupted. Please perform the following steps to locate the device file: 1. In the windows search bar type "cmd" and then select "Command Prompt". 2. In the command prompt please type "echo %USERPROFILE%" and press enter. This should cause the path to your user profile to be displayed. It should be something like "C:\Users\John Doe". 3. Open file explorer and navigate to the directory that was listed for %USERPROFILE%. 4. Go into the "AppData directory. This is a hidden folder so you might have to type in a path such as "C:\Users\John Doe\AppData". 5. You will likely see 3 sub-directories: "Local", "LocalLow", and "Roaming". If "Roaming" exists then enter that folder and look for Digilent. If there's a Digilent folder enter that directory and if "dvctbl.txt" exists delete it. If you don't find "C:\Users\John Doe\AppData\Roaming\Digilent\dvctbl.txt" then you can try "C:\Users\John Doe\AppData\Local\Digilent\dvctbl.txt" and "C:\Users\John Doe\AppData\Local\Digilent\dvctbl.txt". Please let me know if the issue persists after deleting dvctbl.txt. Thanks, Michael
  15. Hi @3NTHI0S Sorry the delayed response - I've been traveling overseas for the past 2 weeks. Based on your console output it appears the issue is that the udevd process isn't running so the script assumes that hotplug is used, which is why you are receiving an error. I'm not sure why UDEV isn't running on your system, but without it you may not be able to access the device without root. I'm glad to hear that it works when using the debian package. At some point I might rewrite the script in the tar.gz to remove the check for UDEV vs hotplug but you are the first person to mention this issue and I have a lot of other things in my queue. Thanks, Michael
×
×
  • Create New...