All Activity

Hi Paul, Yeah, this is a result of the local memory being too small. It's come up in other threads, and as I understand it, you can adjust the memory size from the Address Editor: Thanks, Arthur

Hi @artvvb [Aha, that does work fine if I'm typing, just not when I copy/paste. Thanks.] Cheers for those references. I've been working through the '.../getting-started-with-ipi' guide that you linked, to try out a basic MicroBlaze C project. As you suggested, I followed the steps for boards without DDR memory (even though it's present on my board). I've nearly made it to the end of the guide, but am now hitting this error in Vitis when I try to build the C code: [...] /home/pdw/Xilinx/Vitis/2022.1/gnu/microblaze/lin/x86_64-oesdk-linux/usr/bin/microblaze-xilinx-elf/microblaze-xilinx-elf-ld.real: microblaze_flash_wrapper_app.elf section `.heap' will not fit in region `microblaze_0_local_memory_ilmb_bram_if_cntlr_Mem_microblaze_0_local_memory_dlmb_bram_if_cntlr_Mem' /home/pdw/Xilinx/Vitis/2022.1/gnu/microblaze/lin/x86_64-oesdk-linux/usr/bin/microblaze-xilinx-elf/microblaze-xilinx-elf-ld.real: region `microblaze_0_local_memory_ilmb_bram_if_cntlr_Mem_microblaze_0_local_memory_dlmb_bram_if_cntlr_Mem' overflowed by 1856 bytes collect2.real: error: ld returned 1 exit status make: *** [makefile:38: microblaze_flash_wrapper_app.elf] Error 1 My guess is that this error is caused by a mistake I made, much earlier in the tutorial. I misunderstood what the 'Local Memory' setting was referring to when configuring the MicroBlaze IP block, and so (thinking that I wouldn't need much of it) I set it to 8k rather than 32k. I've had a poke around in the block diagram and I now can't see any way to alter this setting. (Specifically, I'm wanting to alter the 'Local Memory' value that was originally set via the Run Block Automation dialog when I added the MicroBlaze IP to the diagram.) But this isn't too surprising, as I also note that the tutorial, in the section on configuring the MicroBlaze, has this to say: So, I've got two questions at the moment: Could that 'Local Memory' setting really be the cause of the compiler error I'm seeing? If so, is there a better way to fix that setting now, without needing to wipe the block diagram (and rebuild it correctly this time)? Many thanks, Paul.

Hi @artvvb [Aha, that does work fine if I'm typing, just not when I copy/paste. Thanks.] Cheers for those references. I've been working through the '.../getting-started-with-ipi' guide that you linked, to try out a basic MicroBlaze C project. As you suggested, I followed the steps for boards without DDR memory (even though it's present on my board). I've nearly made it to the end of the guide, but am now hitting this error in Vitis when I try to build the C code: [...] /home/pdw/Xilinx/Vitis/2022.1/gnu/microblaze/lin/x86_64-oesdk-linux/usr/bin/microblaze-xilinx-elf/microblaze-xilinx-elf-ld.real: microblaze_flash_wrapper_app.elf section `.heap' will not fit in region `microblaze_0_local_memory_ilmb_bram_if_cntlr_Mem_microblaze_0_local_memory_dlmb_bram_if_cntlr_Mem' /home/pdw/Xilinx/Vitis/2022.1/gnu/microblaze/lin/x86_64-oesdk-linux/usr/bin/microblaze-xilinx-elf/microblaze-xilinx-elf-ld.real: region `microblaze_0_local_memory_ilmb_bram_if_cntlr_Mem_microblaze_0_local_memory_dlmb_bram_if_cntlr_Mem' overflowed by 1856 bytes collect2.real: error: ld returned 1 exit status make: *** [makefile:38: microblaze_flash_wrapper_app.elf] Error 1 My guess is that this error is caused by a mistake I made, much earlier in the tutorial. I misunderstood what the 'Local Memory' setting was referring to when configuring the MicroBlaze IP block, and so (thinking that I wouldn't need much of it) I set it to 8k rather than 32k. I've had a poke around in the block diagram and I now can't see any way to alter this setting. (Specifically, I'm wanting to alter the 'Local Memory' value that was originally set via the Run Block Automation dialog when I added the MicroBlaze IP to the diagram.) But this isn't too surprising, as I also note that the tutorial, in the section on configuring the MicroBlaze, has this to say: So, I've got two questions at the moment: Could that 'Local Memory' setting really be the cause of the compiler error I'm seeing? If so, is there a better way to fix that setting now, without needing to wipe the block diagram (and rebuild it correctly this time)? Many thanks, Paul.

Hi RATHNA, Digilent currently doesn't support Code Composer Studio for any of our products. Thanks, Arthur

Is there a way to get a copy of ULxLV.dll from the Labview 8.5 era?

Thanks, @JColvin! Would love to get this conversation started.

I'm using Vivado 2023, but I believe that particular adept version was added by ISE, since the dates of the files do match with the ISE installation! Many thanks again for taking time on this S

Hi @attila So, if I understand you correctly, I configure and run my pattern with DigitalOut_SPI.py and then use DigitalIn_Spi_Spy.py to capture the data. Correct? I tried to run the example DigitalOut_SPI.py but nothing seems to toggle. I attached the code I am running. DigitalOut_SPI.py

Hi @attila So, if I understand you correctly, I configure and run my pattern with DigitalOut_SPI.py and then use DigitalIn_Spi_Spy.py to capture the data. Correct? I tried to run the example DigitalOut_SPI.py but I could not see how to make it run for a certain amount of time like 1hr. DigitalOut_SPI.py

@scorbetta This makes a lot more sense now because support for network devices was added in 2020. To the best of my knowledge Vivado includes the libraries in a subdirectory underneath the Vivado directory and loads them from there. This is something I can confirm with Xilinx - can you tell me which version(s) you have installed? I think at one point we were installing files in /usr/local/lib64 but moved to /usr/lib64, so it's possible that those files may be left over from an older installation that was performed using the install script from the tar.gz instead of the debian package manager. I believe that warning message you are seeing can safely be ignored. Thanks, Michael

@malexander I might have found something. The output of `ls -al /usr/local/lib64/digilent/adept/libdmgr* -l` is the following: lrwxrwxrwx 1 root root 16 apr 5 09:21 /usr/local/lib64/digilent/adept/libdmgr.so -> libdmgr.so.2.7.2 lrwxrwxrwx 1 root root 16 apr 5 09:21 /usr/local/lib64/digilent/adept/libdmgr.so.2 -> libdmgr.so.2.7.2 -rwxr-xr-x 1 root root 25529 apr 5 09:21 /usr/local/lib64/digilent/adept/libdmgr.so.2.7.2 which makes me believe the library under /usr/local/lib64 is the wrong version. I then checked under `ls -al /usr/lib64/digilent/adept/libdmgr* -l` since you both pointed out and the output is lrwxrwxrwx 1 root root 17 gen 30 2023 /usr/lib64/digilent/adept/libdmgr.so -> libdmgr.so.2.11.9 lrwxrwxrwx 1 root root 17 gen 30 2023 /usr/lib64/digilent/adept/libdmgr.so.2 -> libdmgr.so.2.11.9 -rw-r--r-- 1 root root 18856 gen 30 2023 /usr/lib64/digilent/adept/libdmgr.so.2.11.9 Now, the output of the `nm` command you asked me to issue earlier now changes to: 0000000000002583 T DmgrAddAccount 0000000000002746 T DmgrCancelTrans 0000000000002632 T DmgrChangeAccountPassword 0000000000002366 T DmgrClose 00000000000028e7 T DmgrClrFsadm 00000000000025b4 T DmgrDeleteAccount 0000000000002836 T DmgrDvcTblAdd 000000000000286a T DmgrDvcTblClear 0000000000002850 T DmgrDvcTblRem 0000000000002875 T DmgrDvcTblSave 00000000000023ae T DmgrEnableControlChannelTLS 00000000000023c5 T DmgrEnableDataChannelTLS 0000000000002561 T DmgrEnableDisableClientAuthentication 0000000000002410 T DmgrEnumDevices 000000000000242a T DmgrEnumDevicesEx 0000000000002500 T DmgrFreeDvcEnum 00000000000025d9 T DmgrGetAccountAttributes 000000000000265f T DmgrGetAccountList 0000000000002880 T DmgrGetDtpCount 000000000000288b T DmgrGetDtpFromIndex 00000000000028ad T DmgrGetDtpString 00000000000024bc T DmgrGetDvc 000000000000296a T DmgrGetDvcFromHif 00000000000024de T DmgrGetEdvc 00000000000024a2 T DmgrGetEnumCount 00000000000026ef T DmgrGetInfo 0000000000002308 T DmgrGetLastError 0000000000002394 T DmgrGetNetworkConnTimeout 0000000000002522 T DmgrGetNetworkEnumTimeout 0000000000002940 T DmgrGetSysInfo 0000000000002719 T DmgrGetTransResult 000000000000277c T DmgrGetTransTimeout 00000000000022d0 T DmgrGetVersion 000000000000253c T DmgrIsClientAuthenticationEnabled 00000000000027e6 T DmgrIsControlChannelSecure 00000000000023dc T DmgrIsControlChannelTLSEnabled 000000000000280e T DmgrIsDataChannelSecure 00000000000023f6 T DmgrIsDataChannelTLSEnabled 000000000000248c T DmgrIsEnumFinished 0000000000002313 T DmgrOpen 0000000000002338 T DmgrOpenEx 0000000000002606 T DmgrSetAccountAttributes 00000000000028cf T DmgrSetFsadm 000000000000268f T DmgrSetInfo 000000000000298c T DmgrSetLastErrorLog 00000000000029ae T DmgrSetLastErrorNoLog 000000000000237d T DmgrSetNetworkConnTimeout 000000000000250b T DmgrSetNetworkEnumTimeout 0000000000002916 T DmgrSetSysInfo 000000000000275d T DmgrSetTransTimeout 0000000000002461 T DmgrStartEnum 0000000000002497 T DmgrStopEnum 00000000000029c5 T DmgrSzFromErc 00000000000028ff T DmgrTstFsadm which contains the DmgrSetNetworkConnTimeout symbol. I believe the adept runtime unde /usr/local has been installed by either Vivado or an (old version of) ISE. If I launch waveforms in the following manner: LD_LIBRARY_PATH=/usr/lib64/digilent/adept waveforms it finally loads! I believe the following warning is ok Warning: Ignoring XDG_SESSION_TYPE=wayland on Gnome. Use QT_QPA_PLATFORM=wayland to run on Wayland anyway. Does it make sense to you? Thanks for the support S

Hello! I have a question regarding the counter input port on the DAQ. I have a flow sensor connected to a scaler (F5140 scaler, pdf attached) which will then send a pulse output to the DAQ. On the scaler specs, it asks to supply voltage that the DAQ itself would be able to handle. I am guessing a 12V DC would be appropriate here given the counter ports can handle +-15V right? Also for the DAQ's minimum current requirements for actually being able to read a signal from the scaler, there is no information regarding this in the user guide. I would need this value to determine if I can use the internal pull-up resistor on the scaler or I would have to resort to an external one. Is there any internal pull up on the counter ports of the DAQ and would they have to be disabled here? Your help is highly appreciated! MT Flo-tech-F5140-F5141-manual.pdf Flo-Tech-K-scale-factor-datasheet.pdf

Hi @attila I am using 20pin to 20pin jumper cable, so I had to reconnect all of them together. I just figured out the problem is the digital I/O. (I am controlling relay using source drive + DIO) The reading is bad because only one channel of the relay switched. My suspicion is the drive strength on AD3(default 4mA), where AD2 had 12mA as default. **Is there any way to set DIO drive through LabView?

@scorbetta I don't see DmgrSetNetworkConnTimeout listed in the output which doesn't make sense, as that symbol is present in the latest version of the runtime which I freshly installed using the debian package from our website. Can you please provide the output of "ls -al /usr/local/lib64/digilent/adept/libdmgr.so"? Thanks, Michael

I am running a Microblaze design with the freertos bsp on a Digilent Arty A7. My microblaze design uses the Arty's DDR, Ethernet, and UART. It has an AXIDMA, an interrupt controller and a timer I think. I have an AXI-S interface exiting my block design and talking to a custom IP, as well as a System ILA. When I run/debug the xaxidma_example_sg_poll example code (from https://github.com/Xilinx/embeddedsw/tree/master/XilinxProcessorIPLib/drivers/axidma/examples) I can see the proper data (0x0C - 0x2B) come out of the microblaze and onto the AXI-S interface using my ILA. but the code doesn't ever return from: (xaxidma_example_sg_poll.c - main) ..Status = SendPacket(&AxiDma); (xaxidma_example_sg_poll.c - SendPacket) ..Status = XAxiDma_BdRingToHw(TxRingPtr, 1, BdPtr); (xaxidma_bdring.c - XAxiDma_BdRingToHw) .. XAxiDma_WriteReg(RingPtr->ChanBase, XAXIDMA_TDESC_OFFSET, (XAXIDMA_VIRT_TO_PHYS(RingPtr->HwTail) & XAXIDMA_DESC_LSB_MASK)); Looking at the ILA, all the AXI-S signals seem right. TVALID is high only during the transfer. TREADY is always high. Has anyone had to deal with this or similar types of issues, with the stock dma sg example code? After doing some more debugging, I am still stumped. In the HW, removed my AXI-S peripheral and replaced it with a direct loopback and see the same behavior on the software side, on the hardware side the AXI-S interfaces look the same, minus the latency my AXI-S peripheral was inducing. I've looked at the example code and added printf's all over the place, and observed the BD chain initialization for both the RX and TX channels. I've changed the packet size from the default of 0x20 bytes to 0x200 bytes. According to the UG, the "XAxiDma_WriteReg(RingPtr->ChanBase, XAXIDMA_TDESC_OFFSET, (XAXIDMA_VIRT_TO_PHYS(RingPtr->HwTail) & XAXIDMA_DESC_LSB_MASK))" command is the actual write that starts the DMA HW reading the BD chain, and I have observed that. The WriteReg command is is an alias of xil_out32() and so for it to not return seems to imply either some logic error on the AXIDMA axi-lite interface or some error in the my Block Diagram design that enables a register write to hang forever. But the fact that I see the entire packet go out on the AXI-S interface, implies that, at the least the axi-lite write enable / write strobes get there. It might be notable that the BD ptr (81000000) that is written into the TDESC_OFFSET register is the First/Head BD. The example code appears to check for TXSOF and TXEOF, and appears to send a single packet that lives at one contiguous memory location, so that seems like only processing 1 BD would be correct. It's also notable that the xaxidma_sg_intr.cc and xaxidma_sgcyclic_intr.cc examples hang at the same call, on XAxiDma_bdringToHw(TxRingPtr...). I’ve added another ila to look at the axi-lite interface to the DMA. It looks right too. I can see the TAILDESC data value (0x81000000) going on WDATA line, The TAILDESC addr (0h010) going on the AWADDR line in clk later, then both the AWVALID and WVALID lines going high 2 clks later, The AWREADY and WREADY signals gloing high it looks like 23 clocks later, and then both the VALIDs and READYs dropping 1 clk later, and then 1 clk later the BVALID goes high and 1 clk later BVALID and BREADY drop low. I’m running out of ideas. 1) modify the example to process and send 2 BDs. 2) Add a slice register to the AXI interconnect on that MAXI port? 3) tinker with the code to see if I can ever execute a read/write to the the TAILDESC register? Everything seems right but the processor hangs. “stalled on memory access.”

Upon further investigation, this appears to be part of how W7-32B allocates PCI devices memory. In particular, it appears that PCI devices, no matter the device, are always given the 3-4GB Address range. No exceptions. So this is not an issue with the DIO24 cards, but rather W7-32B. It is also largely unsolvable, and the only real options to reduce hardware reserved allocations are through IGP/DVMT settings.

Upon further investigation, this appears to be part of how W7-32B allocates PCI devices memory. In particular, it appears that PCI devices, no matter the device, are always given the 3-4GB Address range. No exceptions. So this is not an issue with the DIO24 cards, but rather W7-32B. It is also largely unsolvable, and the only real options to reduce hardware reserved allocations are through IGP/DVMT settings.

I ran Dell Command/Windows updates but still ran into the same issue. I wanted to check if there's anything specific you know of that may work before we need to look into purchasing a new DAQ device.

I am also copying @malexander for visibility on the Adept side of things.

Hi @AKA What header are you reconnecting ?

Hi, Wanted to follow up on this question. Project was stopped temporarily and now working on it again. When I use the github example, I run into the following MATLAB error after start(dq, "continuous") Warning: Flushed preloaded data. Property "IsContinuous" not supported for Digilent hardware. Also tried it with the "repeatoutput" instead of "continuous". Any idea how I can get around this? Thanks, Dominic

After starting the VI MSO/1 reads correct output but MSO/2 is reading noise. After I disconnect the header and reconnect it, the output fixed itself. This same code works for AD2 but when I use AD3 I have to re-plug the header.

I checked with my manufacturing department about your device. It was discontinued in 2016 and never put into production at Measurement Computing, so I'm sorry to say it is not eligible for repair.

The example programs read with READ_ALL_AVAILABLE. For me, this meant that fragments of the 4-byte variables were also read. That's why I want to determine beforehand how many samples are in the buffer. However, the mcc172_a_in_scan_status function shows strange behavior. If it has not yet been read with mcc172_a_in_scan_read, mcc172_a_in_scan_status always reads a 0. Only when at least 1 value has been read will the number of values be displayed correctly. Am I doing something wrong? do { // Since the read_request_size is set to -1 (READ_ALL_AVAILABLE), this // function returns immediately with whatever samples are available (up // to user_buffer_size) and the timeout parameter is ignored. //////////////////////////////////////////////////////////////////////////////////////////////////////////////// result = mcc172_a_in_scan_status(address, &scan_status, &samples_to_read); STOP_ON_ERROR(result); printf("read %u status %i\r\n", samples_to_read, scan_status); if (samples_to_read == 0)samples_to_read=1; //if i don´t have this, nothing will be read at all... result = mcc172_a_in_scan_read(address, &read_status, samples_to_read, timeout, read_buf, user_buffer_size, &samples_read_per_channel); STOP_ON_ERROR(result); if (read_status & STATUS_HW_OVERRUN) { printf("\n\nHardware overrun\n"); break; } else if (read_status & STATUS_BUFFER_OVERRUN) { printf("\n\nBuffer overrun\n"); break; } total_samples_read += samples_read_per_channel; ... }

@malexander 1. Nothing is attached 2. The error shows up immediately 3. The output is empty. Here's the output of `nm -D --defined-only /usr/local/lib64/digilent/adept/libdmgr.so | grep -i dmgr` instead: 0000000000001ae8 T DmgrCancelTrans 0000000000001960 T DmgrClose 0000000000001bf8 T DmgrClrFsadm 0000000000001b5e T DmgrDvcTblAdd 0000000000001b76 T DmgrDvcTblRem 0000000000001b8e T DmgrDvcTblSave 0000000000001976 T DmgrEnumDevices 000000000000198e T DmgrEnumDevicesEx 0000000000001a3a T DmgrFreeDvcEnum 0000000000001b9a T DmgrGetDtpCount 0000000000001ba6 T DmgrGetDtpFromIndex 0000000000001bc4 T DmgrGetDtpString 0000000000001a1c T DmgrGetDvc 0000000000001c70 T DmgrGetDvcFromHif 0000000000001a04 T DmgrGetEnumCount 0000000000001a96 T DmgrGetInfo 0000000000001908 T DmgrGetLastError 0000000000001c4a T DmgrGetSysInfo 0000000000001abc T DmgrGetTransResult 0000000000001b1a T DmgrGetTransTimeout 00000000000018bc T DmgrGetVersion 00000000000019ec T DmgrIsEnumFinished 0000000000001914 T DmgrOpen 0000000000001934 T DmgrOpenEx 0000000000001be2 T DmgrSetFsadm 0000000000001a46 T DmgrSetInfo 0000000000001c8e T DmgrSetLastErrorLog 0000000000001cac T DmgrSetLastErrorNoLog 0000000000001c24 T DmgrSetSysInfo 0000000000001afe T DmgrSetTransTimeout 00000000000019c2 T DmgrStartEnum 00000000000019f8 T DmgrStopEnum 0000000000001cc2 T DmgrSzFromErc 0000000000001c0e T DmgrTstFsadm 4. Here's the output total 12 drwxr-xr-x 3 root root 4096 apr 17 17:49 . drwxr-xr-x 14 root root 4096 ott 19 11:03 .. drwxr-xr-x 3 root root 4096 apr 17 17:49 digilent lrwxrwxrwx 1 root root 42 gen 2 14:22 ld-linux-x86-64.so.2 -> /lib/x86_64-linux-gnu/ld-linux-x86-64.so.2