cube1us

Members
  • Content Count

    7
  • Joined

  • Last visited

  1. Thanks. That makes sense. In the case of how the tutorial is configured up until 6.4, the only path to the cellular ram is via M_AXI_DP. they (meaning whomever developed the tutorial) could not also connect M_AXI_IP to the same AXI Interconnect, so they added a second AXI interconnect ( and used the two cached connections) - but didn't put that in the instructions. (As a guess, it was a case of originally having used just the local memory connect with an earlier release of lwip, but then lwip got bigger / had more buffers by default, so it was changed, but not entirely consistently).
  2. I did see that after I replied. "futzing" underway. -- the last couple of tests I did doofus here programmed the FPGA, but then forgot to actually start the application. <8) . Update: The application will run fine with all of the data related segments assigned to the cellular RAM, but the instruction segments (.text, .ini and, presumably .fini, though I suppose that never actually runs) seem to insist on being in the BRAM. With that, my BRAM is down to 128KB, which is perfectly acceptable - even 256KB would be OK (The lwip echo server application currently needs about 79KB i
  3. Thanks again for the tip. I think I didn't get that right because 1) the name in the SDK supplied with Vivado 2018.2 is slight different than the tutorial - these things happen - (axi_emc_0_MEM0_BASEADDR_Mem0 in 2018.2 vs. axi_emc_0_S_AXI_MEMO_BASEADDR and 2) the address editor did not show axi_emc_0 under the Instruction space, just under the Data space. Perhaps that was because I selected the Microcontroller Preset - I want to minimize the footprint as my project will need a lot of LUTs. And then, when I went to step 11, I did have that entry there (albeit with a slight different name
  4. Thanks for your suggestion. It allowed me to understand what that define was all about, which led me to look more closely at my block diagram, and I discovered that instead of routing the axi_timer_0 interrupt pin to the microblaze_0_xlcconcat In1[0:0] block per the tutorial, I had run the UARTlite interrupt over there (the block connection GUI leaves something to be desired.). The code doesn't need that UART interrupt I presume (it probably just polls it), but does pretty reasonably insist on the one from the Timer block. So, that took care of that issue. Progress. The SDK make is n
  5. Vivado 2018.2, Windows 10, 64 bit. I am trying to follow the example provided by Digilent for their Nexys4 development board (which has no DDR) for generating the LWIP Echo server. I first had an issue where the BRAM that was recommended (64K) was too small - bumping that up to 128K for dlmb and ilmb fixed that. I also found and fixed an issue in lwip202_v1_1 file xadapter.c as well (thanks to a forum post on the Xilinx website) https://reference.digilentinc.com/learn/programmable-logic/tutorials/nexys-4-getting-started-with-microblaze-servers/start However, now I have one I
  6. Thanks for the offer, but I think I will pass on it. I have tons and tons of T-shirts, and no room even for the ones I have.
  7. The Digilent RS232 UART reference component (downloads found on the PmodRS232 and Nexys2 pages, at least), does not do what many (including myself) might expect. If one looks at the documentation, one can see on page 4 that it expects to see 8 data bits PLUS a parity bit. That is quite unusual - most devices sending data over RS232 send a TOTAL of 8 bits (not including the stop and start bits) -- either 7 bits plus parity or 8 bits with no parity. Now, if one doesn't bother to check the parity, and does not send characters one right after the other, or if one includes two stop bits (