TomF

Members
  • Content Count

    19
  • Joined

  • Last visited

Everything posted by TomF

  1. No ideas from you?
  2. 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.
  3. 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?
  4. 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. 🤦‍♂️
  5. Yes, it is the same version (2019.1)
  6. @D@n, 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.
  7. @D@n, 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: "Cannot suspend: TCF errror report: Command: RunControl suspend "JTAG-jsn-Arty [...] Error text: Cannot stop MicroBlaze. Stalled on instruction fetch Error code: 1" Tom
  8. @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
  9. 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...
  10. 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
  11. 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
  12. TomF

    AXI DMA and memory management

    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 malloc'ing space for an array, assigning this pointer address to the DMA. Is this correct? Seems to be a clean solution. Best regards
  13. TomF

    AXI DMA and memory management

    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
  14. 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 should take care of violations I guess. But how does this look for data written by the DMA? How can I make sure that the memory in this address space is unused and how can I allocate it? Best regards
  15. 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!
  16. 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: https://www.avnet.com/opasdata/d120001/medias/docus/178/UG-AES-A7MB-7A35T-G_Arty_OOB_GPIO_demo_V1.pdf 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
  17. 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
  18. 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 GPIO connecting to it.
  19. 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 bootloader does not load anything. When I debug the bootloader by printing something over UART (verbose mode), there is nothing. When I run the system debugger from SDK with the bootloader code, the bootloader starts and sucessfully reads the flash from Address 0xC00000 and my application starts on the microblaze. What am I doing wrong and what can I do to find the problem? Best regards