TomF

Members
  • Content Count

    19
  • Joined

  • Last visited

About TomF

  • Rank
    Member

Recent Profile Visitors

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

  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!