TomF

We want to use the Arty-A7 board to program other Artix hardware. Is it possible to connect the programming pins to another chip when the FPGA from the board has been removed?

The problem that I have is concerning devices where the bitstream is stored in the flash memory and nothing is reprogrammed. So the IP license does not apply here.

I am using Vivado 2019. To be clear, the boards work for some time, weeks or even months but suddenly die in terms of ethernet connection.

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.

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?

No ideas from you?

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.

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?

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. ?♂️

Yes, it is the same version (2019.1)

@d@n，我尝试使用SPI X1模式，该模式不起作用。但是，我尝试将Bootloader和应用程序加载到SDK的Flash上​​。从Flash它运行完美。我只是无法从SDK直接运行它。

@d@n，我已经检查了跳线设置，也已将所有可能的情况放置。我一直安装了Rev E.0的董事会文件，尽管我正在使用Rev. C板，该董事会工作正常。我还需要重建吗？我加载了示例jpeyron在此处发布，它起作用了。我通过从Flash中运行演示来确认UART的作用。当我在Bitstream上运行简单的Hello World应用程序时，它不起作用。在主循环的第一行中有一个断点显示，验证者从未达到它。当我手动暂停执行时，我会收到一个错误消息：“不能暂停：tcf errror报告：命令：runco​​ntrol暂停“ jtag-jsn-arty [...]错误文本：不能停止微封面。停滞在说明中获取错误代码：1“汤姆

@D@n, 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

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...

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