malexander

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

@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

Thank you all for the help.
The problem was in one of the two drivers (the bus one) and in the working policy of the notebook that made it not working .Finally, it worked with these drivers https://digilent.com/reference/software/adept/start?_ga=2.225815646.578235468.1707132485-1962113075.1645638136 .
Hope it will help others in future

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

Hi @Jeremy LAURENT
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:
       DstmTransfer
I 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

@BryanS @attila
I spent some time debugging this and discovered that the Adept Runtime is receiving EACCES when trying to open files with read/write permission in "/tmp". The following call results in -1 being returned when the file already exists and was created by another user, other than root:  
open("/tmp/digilent-adept2-shm-dvtbl", O_CREAT | O_RDWR, S_IRWXU | S_IRWXG | S_IRWXO );
This will ultimately lead to error code 3090 (initialization failed) because we use these files for locking while performing certain operations and if they can't be opened then the system won't function correctly.
The "/tmp" directory has permissions 1777, meaning the sticky bit is set. This means that all users have read, write, and execute permissions for all files in "/tmp" but only root or the user that created a file in "/tmp" may delete it. This is fine since our software doesn't delete the files that it creates in "/tmp". After seeing the EACCES error I decided to run some experiments using 3 different user accounts: "malexander", "adept", and "root".
Test 1: Ubuntu 20 LTS with sticky bit set for "/tmp"
1. As user "adept" execute "touch /tmp/blah.txt"
2. As user "adept" execute "chmod 777 /tmp/blah.txt"
3. As user "malexander" execute "echo "test" > /tmp/blah.txt" and receive "-bash: /tmp/blah.txt: Permission denied"
4. As user "root" execute "echo "test" > /tmp/blah.txt" and receive "-bash: /tmp/blah.txt: Permission denied"
5. As user "adept" execute "rm /tmp/blah.txt" to remove the file
6. As user "root" execute "touch /tmp/blah.txt" and "chmod 777 /tmp/blah.txt"
7. As user "malexander" execute "echo "test" > /tmp/blah.txt" and receive no error.
8. As user "adept" execute "echo "test2" >> /tmp/blah.txt" and receive no error.
9. As user "adept" cat file "/tmp/blah.txt" and see the expected text:
test
test2
10. As "root" execute "rm /tmp/blah.txt"
Test 2: Ubuntu 20 LTS with sticky bit cleared for "/tmp"
1. As user "root" execute "chmod 777 /tmp" to remove sticky bit
2. As user "adept" execute "touch /tmp/blah.txt" followed by "adept" execute "chmod 777 /tmp/blah.txt"
3. As user "malexander" execute "echo "test" > /tmp/blah.txt" and receive no error.
4. As user "root" execute "echo "test2" >> /tmp/blah.txt" and receive no error.
5. As user "adept" cat file "/tmp/blah.txt" and see the expected text:
test
test2
Test 3: On Ubuntu 20 LTS run Adept test suite DmgrEnumExt test from multiple user accounts without removing the files in "/tmp" between runs with sticky bit off.
1. First make sure that no adept files are presently in the /tmp dir by executing "rm /tmp/digilent*" as root
2. As user "adept" execute "./test DmgrEnumEx -w 2000" and get expected result:
0:    ADP3450-1
    Transport Type:  TCPIP
    Hostname:        10.1.112.148
    IP Address:      10.1.112.148
    Port:            33890
    Account:         
    Password:        
    UsrName:         ADP3450-1
    ProdName:        Analog Discovery Pro 3450
    SN:              SN:210018AFF319
    MAC Address:     MAC:00-18-3E-03-94-5E
    DCAP:            00000008
    PDID:            40720410
PASS
3. As user "malexander" execute "./test DmgrEnumEx -w 2000" and get expected result:
0:    ADP3450-1
    Transport Type:  TCPIP
    Hostname:        10.1.112.148
    IP Address:      10.1.112.148
    Port:            33890
    Account:         
    Password:        
    UsrName:         ADP3450-1
    ProdName:        Analog Discovery Pro 3450
    SN:              SN:210018AFF319
    MAC Address:     MAC:00-18-3E-03-94-5E
    DCAP:            00000008
    PDID:            40720410
PASS
Test 4: On Ubuntu 18 repeat test 1 with the sticky bit enabled (default on startup). The results under Ubuntu 18 were different. Any user can write a file that was created by another user in "/tmp" as long as the permissions for the file are set to 777. This is the behavior I expected.
Test 5: On Ubuntu 16 repeat test 1 with the sticky bit enabled (default on startup). The results under Ubuntu 18 were different. Any user can write a file that was created by another user in "/tmp" as long as the permissions for the file are set to 777. This is the behavior I expected.
Conclusion:
I think this issue is the result of a bug in Ubuntu 20. Sure, it's possible that the behavior in Ubuntu 16 and Ubuntu 18 is the result of a bug that was fixed in Ubuntu 20. However, I think that's unlikely since we've never received reports of this issue on any other distribution. Further, the code that's being executed hasn't changed in years.
I'm not sure who to contact about this issue to get it fixed upstream in Ubuntu 20 but I'll try to find someone.
For now the only workaround I can suggest for people running Ubuntu 20 is to execute "chmod 777 /tmp" as root on startup to remove the sticky bit.

@Kyle_Jackson
I was able to get the SREC bootloader working on a Cmod A7 - 35T that has the Macronix flash using Vivado 2019.1. To get this to work you have to include the Xilinx QSPI controller in your Microblaze block design and in the IP configuration either select "Standard" for the mode (SPI x1 mode) or if you select "QUAD" then make sure to select "Macronix" for Slave Device.
Once you are in SDK and have created the SREC bootloader project (and associated BSP) you need to open "bootloader.c" from the sources and scroll down until you find the call to "XIsf_Initialize". Double click the function name to highlight it, right click and select "Open Declaration". Once you have "xilisf.c" open do the following:
1. Somewhere near the top of xilisf.c add the following:
#define XISF_MACRONIX_DEV_MX25L3233F    0x2016  /**< Device ID for MX25L3233F */
2. In xilisf.c find the definition for IntelStmDevices[] and add the following:
{XISF_MANUFACTURER_ID_MACRONIX, XISF_MACRONIX_DEV_MX25L3233F,
          XISF_BYTES256_PER_PAGE, XISF_PAGES256_PER_SECTOR,
          XISF_NUM_OF_SECTORS64},
3. Save xilisf.c, which should rebuild the project.
Once you've completed the above steps you need to go through the process of generating a download.bit that has integrated the bootloader elf with the bitstream, program that to the flash at offset 0, and then program your application SREC to the flash at the appropriate offset. I placed my SREC at offset 0x00180000 (same offset I set in blconfig.h of the srec bootloader project) since my bitstream was only ~1100KB. You may need to use a different offset depending on the size of your bitstream+bootloader elf combination.
I suggest that anyone who is unfamiliar with the SREC bootloader process follow the guide linked below but select "Macronix" for the Slave Device and perform the xilisf.c modifications.
https://reference.digilentinc.com/learn/programmable-logic/tutorials/htsspisf/start
Thanks
Michael

We've updated our procedures to ensure that the modules will be easily identifiable whenever a change to form, fit, or function is made. There will also be a PCN issued before new modules go into distribution.