• Content Count

  • Joined

  • Last visited

About hdx

  • Rank

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Hi again, I have now continued, and when now running the timer interrupts the rtos tasks seem to stop working. When the timer has finished with the interrupts needed it stops and then nothing happens. When debugging the rtos tasks it seem like they have stopped running after the timer interrupt were triggered. Why is that? Moreover I have now noticed that there is a xintc definition inside the rtos files in xilinx sdk. Should I be using these or can I still declare each modules own xintc variable?
  2. Hi, I am trying to trigger a Timer interrupt in a very high speed few thousand times to read an adc whenever I start the pwm signal. I am running an RTOS with 3 different tasks and want that during runtime I'll be able to send a request to start a pwm signal and enable timer interrupts to start also. However, whenever I do this, the RTOS tasks start to act weird and start to run continously when the task should run each 10 seconds. What I guess is that there is some kind of out of sync that happens or something that triggers the tasks to run the whole time? What could have happened?
  3. Hello, I have a project where I am using an MC33972 to trigger an GPIO interrupt when state changes. The problem I am facing currently is that when the interrupt is triggered, the callbackref to the gpio handler is receiving an incorrect instance. Whenever the handler is triggered the application crash and get stuck due to that the callbackref I receive is belonging to the INTC instanceptr and not the XGPIO instanceptr, so when calling XGpio_InterruptGetStatus(gpio_ptr); the application fails on the asserts as they are incorrect and not belonging to the XGPIO but instead INTC. Has an
  4. Hello, I have now for a few days tried to debug and see where the problem is, however can't seem to get any understanding why the SPI would cause this problem, specially for only the mc33972 when the both mc33972 anhd ADS8638 are connected to the same ip block but with different CS. From the debugging I have made I have noticed also if I comment out the usage of mc33972 that the interrupt triggers but when getting the gpio interrupt status it fails, and this is due to that it says that the flag bit in the passed instance ptr is 0x22222222??? When checking the ptr it seems to be
  5. Hello, Yes that is correct the same SPI IP is shared between MC33972 and ADS8638. The MOSI, MISO AND SCK is shared between these two modules, but the CS is unique for each module. I'll look into these threads and see if I could find something that would solve this problem. The weird thing is how the interrupt for an GPIO could cause the SPI IP from working.
  6. Hi, Thanks for the help. The SPI devices works flawlessly when using them without the interrupts for my GPIO ports.However, As fast as I enable the GPIO interrupt the mc33972 device fails to transmit data. So everything is working correctly but the interrupt somehow does something that cause the mc33972 to fail. I have configured the devices correctly with right options so should not be the problem also the clocking in hardware is set correctly. I might suspect that there is something that cause the transmit tx empty bit not to be set when the interrupt is enabled. I'll continu
  7. Hello, I am currently using the FPGA to run an ADS8638 and mc33972 by switching between the CS. The problem I have noticed is that when I run the init for both the work perfectly however after initializing an GPIO interrupt on my board the mc33972 SPI stops working and just halts when performing an XSpi_transfer(). However, it still is working for the ADS8638. Both ADS8638 and mc33972 are using the same SPI IP with same address and id, i.e., it is shared between each other. But, XSpi_transfer from ADS8638 works without any problem but not for mc33972 after running this function in interru
  8. I have not made any changes on the SDK code itself, I am using the "echo server" application that can be created and generated by anybody that are using the xilinx sdk application.
  9. Hi, After several hours of trail and error, trying to debug and understand what the problem is, I finally managed to get it to work! The solution was as you've mentioned with the MII mode. I had to set the eth_rx_dv pin manually to high to set the PHY into RMII mode, this was solved finally by creating a gpio block with one output and setting the default value to 0xFFFFFFFF. Afterwards the rmii mode was activated! Thank you for all the help @toshas!
  10. I have tried to set the pin as pull-up, but I'm unsure whether this is correct or not?
  11. Hi, Thank you for all the help, I really appreciate it Ok I'll try 50MHz clock reference instead. However, if I remember correctly I had some problems getting the ethernet port to work as it was giving me on the pc that the ethernet port was off, will give it a try again anyways. Might be something with the pull-up as you've mentioned, as it needs to be switched to rmii mode Regarding the ethernet port, I am using the arty a7 35-t dev board which has a ethernet connector by default onboard, same as can be found in this link: https://reference.digilentinc.com/reference/programma
  12. Yes, that's correct. I had excluded both rx[1] and tx[1] from the constraints and the ports, however, when I connected the ports to the ip core block it marked them as [1:0] so added just tx[1:0] but not rx. I have now tried to add it in the constraints file, both rx and tx -> [0] & [1], and also changed the ports to range from 0->1, but, still I'm not able to connect to the device. I Have also tried to change the configure_IEEE_phy_speed_emaclite function, to the register as per suggestion(0x17), but still can't connect. The configurations inside the constraints file seem to be corr
  13. Thanks @toshas! I'll check the files and get back with an update.
  14. Hi @toshas, Thank you for the help! I have tried to modify xemacliteif.c source file with suggested changes you proposed, but still have the same problem. I am using the ethernetlite core connected to a mii->rmii core as can be seen in the image in the first post. Also, I am running xilinx vivado 2019.1, sdk is also the same version The arty a7 35-t board I am using, is utilizing an TI Ethernet PHY (DP83848), not DP84838 as in your case unfortunately- My configure_IEEE_phy_speed_emaclite function in xemacliteif.c file looks like this without any changes: (I am u
  15. Hi @JColvin Thanks for the reply! I am currently using vivado 2019.1 and indeed the block is discontinued. Does this effect anything when I am trying to use reduced mii? The application was working without any problems when using only ethernetlite, but when I integrated the mii2rmii I am not able to get any connection with the application server or able to send anything to the device. I am successfully able to generate the bit file and am not getting any errors when generating it. I have the following constraints that I extracted from the master file for arty 35-t: set_