• Content Count

  • Joined

  • Last visited

About TomF

  • Rank

Recent Profile Visitors

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

  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