Mahdi

Members
  • Content count

    29
  • Joined

  • Last visited

About Mahdi

  • Rank
    Member

Recent Profile Visitors

232 profile views
  1. Hello, I am working on a dual core project with mailbox IP on a Arty Z7-10 board which has been acting inconsistently. In my project, 1st core is receiving data from FPGA and sending it through mailbox to the 2nd core; the 2nd core is supposed to receive and write them to the SD card. I need to write the data at 0.5 to 1 MB/s speed, so I can not read and write fast enough on one core. As an example to show the problem, I am writing a number to the card that is being incremented by one on a loop, and plot that versus the clock cycles. Supposedly, my output should look like a straight line which it does if I do all of this on one core. Now, If I use the mailbox to send the same value between two cores, and write it on the 2nd core, I am seeing gaps and overlaps in my data which I am pretty sure is because of Mailbox. Here are two examples of what is happening. If you zoom into the time = 1.0, you can see the following gaps, and overlaps. I have set the size of mailbox at 2048, and made sure that it never fills up by checking its status on every loop. So I wonder what could be the reason for these gaps and overlaps? Can't Mailbox IP transfer data consistently between two cores? Is there any other method for doing such jobs? Thanks, Mahdi
  2. Hi @jpeyron I have good news. Since you insisted on having the delay, I went ahead and re-tested my code again. I filled up my code with delay functions and started to remove them one by one to see where it breaks, and eventually was able to figure out how much delay is needed and where it should be placed. I had several Pmods in my design, so I added 1 second of delay to the beginning and the end of their initialization like below: int main() { init_platform(); sleep(1); RTCC_Initialize(); sleep(1); NAV_Initialize (); sleep(1); GPS_Initialize (); sleep(1); .......... //call get functions here. cleanup_platform(); return 0; } It turns out that with at least 1 second of delay, GPS is functioning normally now. I had tested this with 100 ms or 500 ms delay before, but that did not work out. So, I guess a few seconds of delay seems necessary at the beginning, when we are using FSBL with Pmods. It just seems weird that some of the Arty boards do not need that delay at all, as I explained earlier. Anyway, my problem is solved, so let's just call this the final solution. Thanks again to you and your co-worker, -Mahdi
  3. Hi @jpeyron I tested your ideas, but apparently none of them were able to fix this problem. I used the Pmod GPS example code with FSBL, but I do not see any GPS data on terminal. I also tested it outside, but did not make a difference. In addition, I added a couple of seconds delay at beginning of my C code, which also did not help. I should mention I had a few Pmod GPS devices, and tested all of them individually with the same code I sent you. it seems some of them are working and getting the correct GPS data after boot up with FSBL, but as soon as I try another Pmod GPS device, it stops working. All of those GPS devices are purchased recently, so I do not know where this inconsistency issue is coming from. It seems some of them have difficulties working correctly with FSBL, but the others are fine. Have you ever had such issues before? I am assuming the PmodGPS you had is also part of the ones that have this problem, but why should it be like this? Thanks, Mahdi
  4. Hi @jpeyron I did some follow up tests with the above configuration, but did not see any difference, though it is worth it to mention them. I commented out all of xil_printf statements and removed the inlcude xil_printf.h from the c code, hoping that printing the data to UART terminal was the problem, but it was not. I also tried to boot from SD card instead of QSPI flash memory, but even with that the problem is still there. I am almost running out of ideas and thinking maybe the FSBL is causing the issue, because every other time that FPGA is programmed via USB and there is no boot up, it seems to be working. It is a very strange bug. Thanks, Mahdi
  5. Thanks @jpeyron. I am glad that it is not just me who has this problem. I hope you can find a clue. -Mahdi
  6. @D@n I am not sure what voltage you are referring to, but I am only using either USB or REG to power the board. In case of USB, I am connecting it to my laptop, and look at the terminal output in the SDK software, and in case of REG, I am using power jack port and connect it to a power supply which has a very low noise (Circuit Specialists CSI3005X5 ). Arty board has already a built-in switching regulator in it, I guess. When the board is powered via REG, USB cable is not plugged in. Also, PmodGPS is plugged into one of j-ports on the Arty, so I do not know if there is a switching noise on that power line. This issue does not seems to be due to noise on power line. I guess it has something to do with the fact that GPS library is using a UART connection, and somehow that requires the board to be plugged in via a USB cable. I know this sounds silly, but it is what it is. Thanks, Mahdi
  7. Hi @jpeyron I have read all of those tutorial about using FSBL, and I can guarantee that I am doing it correct. I verified that under several tests. If you still doubt that, you can make your own project and use my SDK code to see if there is any difference. I tried to summarize my SDK code as much as possible which is attached, but still the problem is there. As I said earlier if I program Arty via USB port, and look at the terminal, I am seeing the correct NMEA sentence format, but whenever I am uploading the code to QSPI flash memory, the only thing I see in terminal is this: GPS data = <GPS did not get a ping...> which is basically what I initialized my GPS char array with. It seems to me whenever there is a UART connection to the ZYNQ board, GPS is operating fine, but as soon as I unplug the USB from board, and power it via regulator, it stops updating my char array. Does GPS use a USB UART during its operation? I have no idea why this is happening. Thanks, Mahdi main.c
  8. Hi, I have a project that uses Arty Z7-10 with pmodgps to receive the NMEA sentences every few seconds (I am using the GPS_getSentence function directly, rather than the sample code on github). The problem I am facing is whenever I program Arty via JTAG with a USB cable, my pmodgps is working correctly, but If I program the QSPI flash memory and use FSBL to boot it up, it seems to stop working. I have other pmods that are working fine in both cases, and only gps is not working as I am expecting. This seems like a weird bug to me. Does anybody have any idea what could be wrong? Thanks, Mahdi
  9. Hi @jpeyron Awesome! I wish we had tried this earlier instead of dealing with that splitter. All 3 Pmods are working perfectly now! I really appreciate your helps. -Mahdi
  10. Hi @jpeyron I believe that is the way to go. I have occupied almost all of the GPIO pins on the Arduino header, but still the Chipkit I2C is available which I guess it is the following lines in the XDC file: ## ChipKit I2C #set_property -dict { PACKAGE_PIN P16 IOSTANDARD LVCMOS33 } [get_ports { ck_scl }]; #IO_L24N_T3_34 Sch=CK_SCL #set_property -dict { PACKAGE_PIN P15 IOSTANDARD LVCMOS33 } [get_ports { ck_sda }]; #IO_L24P_T3_34 Sch=CK_SDA I can easily connect my PmodRTCC to these two ports physically, but how am I supposed to communicate with it in my C code? It was easy to run the PmodRTCC example code while it was connected to ja port, but I have no idea how to talk to it when it is connected to SCL and SCA on the Chipkit. Could you please help me on this part? Thanks, Mahdi
  11. Hi @jpeyron I am not sure if you used the XDC and SDK code I gave you, but my problem right now is far beyond the c code. As soon as I hit the program FPGA button in either Vivado or SDK software, the GPS light goes on, and never turns off again, which makes me think the problem is with the bitstream. Didn't you experience such problem? The C code is the next step which we should be worried about. I am %100 sure that the attached C code is working fine, when there is only one Pmod connected to ja port in block design. Problem starts when we try to communicate with 2 pmods through one port. One thing I noticed is that all 6 pins on the top and bottom row of each J-port are electrically connected. I understand that GND and VCC could be shared, but why are the other 4 pins connected? Couldn't such connection mess up the whole splitting of the port? I am working on a project which is very close to its deadline, and the only part that is not cooperating is this port splitting. I realized that there is also a I2C port (J2) on the Arty-Z7-10 which can be used to access devices such as PmodRTCC. Do you think it is doable to connect the PmodRTCC to that port and communicate with it directly? If I do this, can I still use the PmodRTCC.h library? I am not very optimistic that we can get GPS and RTCC both working on one J-port. Thanks -Mahdi
  12. Hi @jpeyron If I connect each of the Pmods to ja port individually and not make the connections external and follow the normal procedure for making the block design (such as connecting the Pmod to ja port via sources tab of Vivado), I can see the correct output in the terminal with the same SDK code I sent you (of course you need to comment out the other Pmods code), but if I try to modify the wrapper file and XDC file manually the way you said, I can not connect to neither of the Pmods, which makes me think none of the pmods that are sharing a port could be even initialized by this method. If you look at the wrapper file, the PmodGPS and PmodRTCC pins are defined as output (which are sharing ja port) in the module, while the PmodNAV which is taking jb port in declared as inout. I thought this might cause the issue, so I changed the GPS and RTCC pins to inout, but that did not solve the problem either. I hope you can figure this out. Thanks, -Mahdi
  13. Hello again @jpeyron I guess I am still having issues with this setup. As I told you earlier, I got the bitstream generated and imported to SDK. Now, as soon as I hit the program FPGA button, the GPS led goes on and stays on forever which has no meaning to me, unless the wiring would be wrong! but I am sure that both Pmods that share the j-port are plugged in correctly. I took this outside to get a GPS lock, but did not make a difference. Neither GPS nor RTCC are working correct now, even if I just try to initialize and use one of them. My C code freezes right inside initialization of the RTCC (when I am calling RTCC_stopClock(&rtc)) which is the first Pmod I am initializing. All these are telling me we are not fully connected to these Pmods in the block design. What do you think the problem is? I have attached my block design, wrapper file, and the C code. Here is my XDC file as well. ## Pmod Header JA set_property -dict {PACKAGE_PIN Y18 IOSTANDARD LVCMOS33} [get_ports Pmod_GPS_JA1] set_property -dict {PACKAGE_PIN Y19 IOSTANDARD LVCMOS33} [get_ports Pmod_GPS_JA2] set_property -dict {PACKAGE_PIN Y16 IOSTANDARD LVCMOS33} [get_ports Pmod_GPS_JA3] set_property -dict {PACKAGE_PIN Y17 IOSTANDARD LVCMOS33} [get_ports Pmod_GPS_JA4] set_property -dict {PACKAGE_PIN U18 IOSTANDARD LVCMOS33} [get_ports Pmod_RTCC_JA7] set_property -dict {PACKAGE_PIN U19 IOSTANDARD LVCMOS33} [get_ports Pmod_RTCC_JA8] set_property -dict {PACKAGE_PIN W18 IOSTANDARD LVCMOS33} [get_ports Pmod_RTCC_JA9] set_property -dict {PACKAGE_PIN W19 IOSTANDARD LVCMOS33} [get_ports Pmod_RTCC_JA10] I did not do anything fancy. I am getting RTCC, GPS and NAV data in a loop and print them to terminal. I should also mention that this c code worked fine with when I only had GPS and NAV in my block design, and as soon as I added RTCC with your method, it stopped working. Thanks, Mahdi design_1_wrapper.v main.cc
  14. Hello @jpeyron I have already tried this, and some other pin numbers combinations such as GPS_out_pin1_io to GPS_out_pin4_io and RTCC_out_pin4_io to RTCC_out_pin4_io and vice versa. But every time I am generating the bitstream, I am getting this error which says: [DRC NSTD-1] Unspecified I/O Standard: 8 out of 154 logical ports use I/O standard (IOSTANDARD) value 'DEFAULT', instead of a user assigned specific value. This may cause I/O contention or incompatibility with the board power or connectivity affecting performance, signal integrity or in extreme cases cause damage to the device or the components to which it is connected. To correct this violation, specify all I/O standards. This design will fail to generate a bitstream unless all logical ports have a user specified I/O standard value defined. To allow bitstream creation with unspecified I/O standard values (not recommended), use this command: set_property SEVERITY {Warning} [get_drc_checks NSTD-1]. NOTE: When using the Vivado Runs infrastructure (e.g. launch_runs Tcl command), add this command to a .tcl file and add that file as a pre-hook for write_bitstream step for the implementation run. Problem ports: GPS_out_pin10_io, GPS_out_pin7_io, GPS_out_pin8_io, GPS_out_pin9_io, RTCC_out_pin10_io, RTCC_out_pin7_io, RTCC_out_pin8_io, and RTCC_out_pin9_io. and [DRC UCIO-1] Unconstrained Logical Port: 8 out of 154 logical ports have no user assigned specific location constraint (LOC). This may cause I/O contention or incompatibility with the board power or connectivity affecting performance, signal integrity or in extreme cases cause damage to the device or the components to which it is connected. To correct this violation, specify all pin locations. This design will fail to generate a bitstream unless all logical ports have a user specified site LOC constraint defined. To allow bitstream creation with unspecified pin locations (not recommended), use this command: set_property SEVERITY {Warning} [get_drc_checks UCIO-1]. NOTE: When using the Vivado Runs infrastructure (e.g. launch_runs Tcl command), add this command to a .tcl file and add that file as a pre-hook for write_bitstream step for the implementation run. Problem ports: GPS_out_pin10_io, GPS_out_pin7_io, GPS_out_pin8_io, GPS_out_pin9_io, RTCC_out_pin10_io, RTCC_out_pin7_io, RTCC_out_pin8_io, and RTCC_out_pin9_io. this error is for the one you recommended. Apparently Vivado wants us to address all of the 8 pins of each pmod individually, and leaving them behind causes this issue. How am I supposed to fix this? Thanks, Mahdi
  15. Hello @jpeyron By following your response on this post, I have almost figured out how to modify the XDC file using the board schematics, but I have one concern. When I am looking at JA header definition in the XDC file, there are 8 lines of code as following. The first 4 lines are for the top row of pmod port, and the rest are for the bottom row. ## Pmod Header JA #set_property -dict { PACKAGE_PIN Y18 IOSTANDARD LVCMOS33 } [get_ports { ja_p[1] }]; #IO_L17P_T2_34 Sch=JA1_P #set_property -dict { PACKAGE_PIN Y19 IOSTANDARD LVCMOS33 } [get_ports { ja_n[1] }]; #IO_L17N_T2_34 Sch=JA1_N #set_property -dict { PACKAGE_PIN Y16 IOSTANDARD LVCMOS33 } [get_ports { ja_p[2] }]; #IO_L7P_T1_34 Sch=JA2_P #set_property -dict { PACKAGE_PIN Y17 IOSTANDARD LVCMOS33 } [get_ports { ja_n[2] }]; #IO_L7N_T1_34 Sch=JA2_N #set_property -dict { PACKAGE_PIN U18 IOSTANDARD LVCMOS33 } [get_ports { ja_p[3] }]; #IO_L12P_T1_MRCC_34 Sch=JA3_P #set_property -dict { PACKAGE_PIN U19 IOSTANDARD LVCMOS33 } [get_ports { ja_n[3] }]; #IO_L12N_T1_MRCC_34 Sch=JA3_N #set_property -dict { PACKAGE_PIN W18 IOSTANDARD LVCMOS33 } [get_ports { ja_p[4] }]; #IO_L22P_T3_34 Sch=JA4_P #set_property -dict { PACKAGE_PIN W19 IOSTANDARD LVCMOS33 } [get_ports { ja_n[4] }]; #IO_L22N_T3_34 Sch=JA4_N I am also looking at the wrapper file, and there are about 16 inout definition for the 2 pmods that I am going to use as following: inout GPS_out_pin10_io; inout GPS_out_pin1_io; inout GPS_out_pin2_io; inout GPS_out_pin3_io; inout GPS_out_pin4_io; inout GPS_out_pin7_io; inout GPS_out_pin8_io; inout GPS_out_pin9_io; inout RTCC_out_pin10_io; inout RTCC_out_pin1_io; inout RTCC_out_pin2_io; inout RTCC_out_pin3_io; inout RTCC_out_pin4_io; inout RTCC_out_pin7_io; inout RTCC_out_pin8_io; inout RTCC_out_pin9_io; I know that these pins should be called in the get_ports functions of XDC file, but how am I supposed to accommodate 16 pins names in only 8 get_ports function? Should I only use pin number 1 to 4 or 7 to 10 or something else? Thanks again, -Mahdi