JColvin

Hi @Ronald Jansen, Do you also have the JTAG HS3 that is unable to be detected by Digilent Adept software, https://digilent.com/reference/software/adept/start? Thanks, JColvin

Hello, To get the Pmod BLE working through a phone application (so that you can get into command mode via the phone application), you will need to first enable UART Transparent service through the serial terminal on the host computer; this is done through the SS command (while in command mode) setting the UART Transparent Service bit high (detailed on page 23 of the RN4781 User Guide).. You can then confirm the UART Transparent service has been enabled through the GK command as detailed on page 26 of the RN4781 User Guide. Remote command itself is started not by the $$$ by the remote application (i.e. phone app); it is instead started by !,1 as shown on page 27 section 2.6.4, to which the BLE should respond RMT>. With regards of connecting the two Pmod BLEs together, you will need to get both modules in UART Transparent service mode via individual serial terminals and then follow directions on page 61; there will likely be other bluetooth devices nearby so you'll need to make sure that you attempt to connect to the correct device rather than a random nearby smart watch. Let me know if you have any questions about this. Thanks, JColvin

Hi @JohnWhite777, Welcome to the Forums!

Hi @Chellam, I will also provide you this contact. @imlcorp, I will contact this person as well to make sure they have seen your query. Thank you, JColvin

Hi @ivrsak, I was able to readily get into command mode through a serial terminal with the Pmod BLE by following the Pmod IPs guide that we have here (in conjunction with this guide for getting the block design made). These include the SDK set that I used. The only deviation I made was for the AXI Uartlite IP (on a non-Zynq design), I set the UART baud rate to be at 115200 rather than the default 9600 because 115200 is the default used by the Pmod BLE. I was then able to connect to it via a phone app, though I was not able to enter command mode on the phone app, but could enter it through the serial terminal. I will get this set up on two different boards (since you mentioned you wanted two BLEs to communicate with each other) and see if I can readily set them up to auto connect with each other and exchange basic data. Thanks, JColvin

Hi @ivrsak, I am working on this same issue with the Pmod BT2 where you can connect to it in the phone application (same application that you are using), but it does not respond to the command mode message of $$$. When using the SDK project, I can go into command mode with a serial terminal, though some of the data I receive back is intelligible. I am looking into this; if I get the Pmod BT2 working correctly, I will see if that also works for Pmod BLE. Thanks, JColvin

Hi @ivrsak, I need to look into this more. Some BLE apps require that more of the secure "digital handshakes" (I don't believe this is the correct terminology for Bluetooth Low Energy) are processed, and I have not gotten that to successfully work as of yet. Thanks, JColvin

Hi @AlexeyTea, Could you download the Digilent Adept system and let us know what you see when you connect to the JTAG SMT3? Additionally, how do you have the JTAG SMT3 NC loaded onto your host board so we can help confirm the implementation side of things? In general, we recommend that you don't use FT_PROG with the Digilent boards as it's very easy to accidentally erase the EEPROM on our boards as evidenced by the many pages of this forum topic. Thanks, JColvin

Hi @LuisMP, I'm not certain on how ISE handled it, but in general the Xilinx tools as well as Adept do not allow you to program a board with a bitstream designed for a different FPGA and would give an error if you tried; I don't think there was a way to force a non-compatible bitstream to load. Unfortunately, we don't offer repair services for our boards, though I can tell you that the L3 coil is a 2.2 uH inductor, which if broken would prevent the 3.3V line from being generated. If both the 2.5V line and the 3.3V do not properly generate their voltages (I presume the 1.2V line is affected as well) then the regulator on IC2 (a Linear Technology LTC3543) is likely broken, which would cause the Done, Prog, and Init lines on the FPGA to be held low so that the FPGA would not be able to be configured. Replacing IC2 would be what I recommend attempting to do, though I do not know if there are other damages on the board besides the L3 inductor that you mentioned. Thanks, JColvin

Hi @LuisMP, I haven't seen this type of error before and I asked another one of our engineers and they hadn't seen it before either. Does this same error appear in the Adept system if you test/connect to it on a different computer? Thanks, JColvin

Hi @Leon.k, I apologize for the delay. I didn't realize you were doing individual wire breakouts from the HS3. I tested this with an Arty and a HS3 and was successfully able to have Adept detect the downstream Artix 35 chip. Could you show me more directly how you have your wires connected to the HS3 side? It looks like the pins are in the correct order, though I'd feel better if I could make sure of that. The other thing I noticed is that the contact leads between the HS3 and the wires that then lead to the Arty A7 are not very long, so there is a possibility that there isn't a clean electrical connection there (and something that I've had to deal with before). Could you move the black plastic spacer down in order to provide more contact between the leads and the wires? Thank you, JColvin

Hi @imlcorp, The email you listed was accurate (I edited it though in the interest of preventing bots from being able to directly copy it). I have sent you a PM with the Digilent contact to discuss licensing, but to answer your other question, no, neither National Instruments nor Xilinx is directly involved with this license. Thanks, JColvin

Hi @Camarillo, Welcome to the Forums! I'm sorry to hear about the potentially broken board, though I'm glad you're enjoying the Analog Discovery's anyway. Thanks, JColvin

Hi @Klavs, I apologize for the delay. I have sent you a PM with some instructions. Thanks, JColvin

Hi @Leon.k, I apologize for the delay. Do you have any device attached to your JTAG HS3? In general, the device ID will be read as all f's like you found if there is not anything attached to the HS3. Additionally, are you only connected to the Arty A7 via the micro USB connector (and not have anything attached via 6-pin JTAG connector, J8)? I can't directly tell from your picture, but I presume the power supply used for the Arty is between 7 and 15V and you have the power selection set to regulated power? Thanks, JColvin

Hi @1bioKAT, The engineer best suited to answer your question is out on medical leave, but I wanted to let you know that we seen your question and have not forgotten it. Thanks, JColvin

HI @Leon.k, I apologize for the delay. What do you mean by lost contact? Is the board still successfully powered? Or do Adept and the Vivado Hardware Manager no longer detect the board? If the latter is the case, the two easy things to check would be to try a different USB port and a different USB cable. I'm not certain why reinstalling Adept would have made a change initially. Thanks, JColvin

Hi @hurricane, I have sent you a PM. Thanks, JColvin

Hi @Stefan0, I asked our layout engineer about this and they provided the following dimension details (attached as an image). Let me know if you have any questions about this. Thanks, JColvin

Hi @Lucifer, I have sent you a PM with some instructions. Thanks, JColvin

Hi @Lucifer, If it's still correctly being detected as the Digilent USB serial converter, then that is a good sign. Could you also see if the cable is successfully recognized by the Digilent Adept software, https://reference.digilentinc.com/reference/software/adept/start? Thanks, JColvin

Hi @Madhusudhan, I have sent you a PM with the instructions. Thanks, JColvin

Hi @Gabriel Degret, I've sent you a PM about this. Thanks, JColvin

Hi @jonpaolo02, I was able to get the WiFi IP working successfully on the Zedboard with Vivado and Vitis 2019.2 This is what I did to get to working : 1. Build Block Design as normal in Vivado 2019.2 (i.e., I followed the Getting Started with Pmod IPs, and used the latest Vivado library zip download from the Digilent GitHub). 2. Create the HDL wrapper for the block design, generate the bitstream, and export the hardware including the bitstream via the File->Export->Export Hardware option. This will create a .xsa file that Vitis uses. 3. Under the Tools option, choose Launch Vitis. 4. After Vitis has successfully launched, choose the "Create Platform Project" under the Project header in the middle of the GUI. Choose a name for it and click Next. 5. Choose "Create from hardware specification (XSA)", click Next, and then browse for the XSA file that Vivado created in step 2. Keep the operating system as standalone and processor as ps7_cortexa9_0. You can choose to keep the Generate boot components checked or unchecked, though I did not test the boot components on my project in the in the interest of having less variables to worry about. (Edit: I tried later to get the boot components working, though have been unsuccessful as of yet) 6. This will create the create the platform in Vitis. I right-clicked on the platform project and chose "Clean Project" followed by "Build Project"; I'm not certain if those steps are a required, though it doesn't hurt. 7. I then clicked on File->New->Application Project. I named the project and clicked Next. Under the "Select a platform from repository" tab, I selected the platform I named earlier (in this case, "Zed-WiFiSD-19-2") and clicked Next. I changed the language used to C++ and maintained the standalone OS on the ps7_cortexa9_0 CPU and clicked Next. I choose Empty Application (since that was the only option) and choose Finish. 8. From there, I followed the same procedure used in SDK 2019.1; i.e., I copied the HTTPServer stored in the [platform_name]->hw->drivers->PmodWIFIF_v1_0->examples folder to the src folder in the application project created in Step 7, and made the changes to deWebIOServerSrc.cpp and HTTPServerConfig.h. 9. At this point, the only thing missing is the .elf file in the application project so it can be successfully launched. I was able to get it generated within the (currently missing) Binaries folder by right clicking on the application project (I choose the one with the "_system" in it's name) and choosing "Clean Project" followed by "Build Project" once the former has finished. This generated the .elf file. 10. There was an error listed in the project that states the .elf for the FSBL was not found, but since the Generate Boot Components option was left unchecked, I ignored this error. After turning on the Zedboard and connecting to it via a serial terminal, I then clicked on the Xilinx tab, chose "Program FPGA", and then right-clicked on the application project and choose Run As->Launch on Hardware. Please let me know if you have any questions about this. Thanks, JColvin design_1_wrapper.xsa vitis_export_archive.ide.zip

@jonpaolo02, I used the master one via the green "Clone or Download" button. The release version looked like it was done prior to the small changes that were made. I'll ask to see if this updated version will get a formal release.