• Content Count

  • Joined

  • Last visited

Everything posted by TomF

  1. There is nothing really special about our setup or environment. As the boards also die when the temperature is low, there must be something else that is not working correctly. One thing I can tell for sure: the ethernet does not have a general problem, as it is working before it fails. The periphery we are using is only some I2C, SPI and the XADC as well as the PHY. The power is supplied by the 9V port of the Arty-A7.
  2. Hello, we are using Arty A7 for prototyping our product which has ethernet connection. After some time, the ethernet connection is not possible anymore and it seems that the PHY is defective. However, it is not clear what could be the cause for this problem. It seems to be independent of the temperature of the environment. The time until it fails is also very random, from weeks to months. Is there a way to find the reason for this and identify the failing component? Are there similar reports concerning this problem?
  3. I rearranged the code, so the SPI interrupt is initialized before the LwIP interrupt. Now it seems the LwIP is unaffected by this routine, but after the first transmission in SPI the Status of the XSpi_Transfer function returns 0x15 (XST_INVALID_PARAM) though I am doing the same stuff as before.
  4. Hello I have a microblaze running a LwIP server adapted from the lwIP server example where everything works fine. LwIP stops working when I use another peripheral with an interrupt attached to it. In my case I have an SPI EEprom running perfectly, but after initialization LwIP stops working. The EEprom code is also standard code from the example. Interrupts are all connected to the microblaze with a concat IP. Has anybody experience in this topic?
  5. Finally solved the problem. It was so easy, but I didnt see it before. The launch button was set to run system debugger on bootloader instead of the firmware. 🤦‍♂️
  6. Yes, it is the same version (2019.1)
  7. @[email protected], I tried it with SPI x1 mode which did not work. However, I tried to load the bootloader and application on the flash from SDK. From flash it runs perfectly. I am just unable to run it directy from SDK.
  8. @[email protected], I already checked the jumper settings, also permutated all possible cases. I always had the board files for Rev E.0 installed, though I was using a Rev. C board which worked fine. Will I still need to rebuild it? I loaded the example jpeyron posted here and it worked. I confirmed the UART works as well by running the demo from the flash. When I run a simple hello world application on my bitstream, it does not work. Having a breakpoint in the first line of the main loop shows, that the procesor never reaches it. When I manually pause the execution I get an error message:
  9. @[email protected], I had a SPI flash implemented in the design, but didnt use it in SDK yet. I tried the following things: 1. Changed flash type in the SPI block in the block diagram from Micron to Spansion 2. Deleted the SPI block None of these worked, I still get no response from UART or Ethernet. When I program the Rev. C board with the new bitstream and microblaze binary, it still works. Tom
  10. As my project is quite large by now and works on the Rev C hardware, is there no other way to troubleshoot it? Only the Rev E boards makes the problems though the board files are for Rev E...
  11. Thank you for your help, Jon 1. Bit file loads 2. Its a microblaze design 3. The done LED is lit, neither UART nor Ethernet do work. 4. The GPIO demo from flash runs, also the linked demo works. Best regards Tom
  12. I just bought a second Arty A7-35T board which is a Rev. E board, my first one is a Rev C board. With this Rev C, I successfully generated a design which works fine though the board files are from Rev. E. Now, I program the new board with the working binaries and if does not work. What can I try to make it work? Best regards
  13. Thank you for your answer, @jpeyron I think I get an idea how it is organized, but it still doesn't satisfy me completely. Concerning your points I have some thoughts: 1. The control register space is always different from the MIG memory, isn't it synthesized as a real register in the AXI peripheral? 2. The only way I see to prevent the DMA from pointing to MIG memory that is used by the application (to my current knowledge quasi-random), so I would need to restrict it in the address editor or by assigning a "safe" address in my microblaze code. 3. I understand this by mall
  14. Thank you @jpeyron, the driver is quite clear to me, but if included I must have missed the part where address space gets reserved in a way that it does not collide with the application memory. If there is somememory allocated by the microcontroller for some function and I assign this space to the DMA accidentally, data will be overwritten and the code will behave unintendedly. How can I be sure to use a free memory space? Best regards
  15. Hello, I have implemented a design with microblaze and a AXI DMA connected to it. When using the address editor it is clear, that the DMA needs to have the access to the same address range as the mig_7 in order to write data to the RAM. When I use the DMA together with a microblaze program, who takes care of memory access violations? When I use a bootloader to load the program into RAM, there should be some space reserved, but this is something that happens before the microblaze code is executed. When I assign/allocate some memory for variables in the microblaze code, the processor s
  16. Hi @jpeyron, I got it working now by creating a fresh project. I will now move on to port my previous PL to the new project and shold get everything running. Thank you for your help!
  17. Your example works fine on my hardware. The only things that I was able to find to be different from my design is the bitstream settings. They are also different from the avnet manual: After adjusting the bitstream settings to be the same as yours, Vivado throws an error message: "invalid stof argument". I am stuck at this point
  18. In case of the same as AXI clock it is 83.33 MHz, on separate clock it is 66.66Mhz. I will try your example now
  19. Hi jpeyron, thank you for your reply. The digilent board files are installed and I used the board macro to initialize the qspi for the flash. I have chosen 16kb for Cache and 32bkb local memory, as described in "Getting started with microblaze servers". I am using the same clock for ext_spi_clk as for the AXI (s_axi_aclk) which is the same for all AXI blocks running on 83.333MHz. I also tried a separate clock from clk_wiiz with 66.333MHz which didn't work either. Please see attached my block diagram. On the lower left there is other logic concerning the PL and some AXI GP
  20. Hello, I am currently working on a Project involving a Microblaze core on an Arty A7 board. Everything works fine by programming the board nonpermantly from Vivado and SDK. I am using 2018.3 and even tried 2019.1 today. However, there is a problem with the startup of the firmware, when I upload it to the flash memory following the "How To Store Your SDK Project in SPI Flash" tutorial. First of all, when I power the device, the FPGA is initialized which I can see by an LED lighting up as it is hardwired to a constant 1. "Done" LED also lights up. The problem is, that the bootload