\Vitis\xv_procss_example_2\Debug\xv_procss_example_2.elf is mapped to address range [80000000:80034BEB], but there is no memory available in that range. Make sure that the data file base address is set to an address corresponding to the memory address range in the design.
Find a linker script in the project tree (typically in "src" folder, called lscript.ld), double-click it, and you will see all sections and which address space they go to. Each line there is a combo-box where you can select any address space which is declared in your BSP as a type of "memory"). See attached screenshot for details.
Also remember that once you compile your binary, you will need to "integrate" it into the bitstream. And you will have to do it every time you make any code changes - unless you run the code directly through Vitis - in which case Vitis will take care of it for you.
Awesome, that has sorted it thanks!
Thanks for the info, I have however noticed that as a minimum, the ones listed as 'MicroBlaze_MCU.....' in the image attached need to be in BRAM otherwise I get the same error above about the base address being wrong.
I cannot put all of them in the 256K of BRAM in my design otherwise it says there is not enough space (approx 95K short) and if I increase to 512K of BRAM in Vivado it totally messes up the timing.
Is it possible to force them all to run off of DDR and not throw up that error relating to the base address being wrong? Or as a minimum to I have to keep the 256K of BRAM in my design and run these from the MicroBlaze with base address 0x00000000?
Just that I am developing on an Artix 7 Series XC7A200T FPGA at the moment on a dev board and it looks like if I can limit the BRAM usage then I could probably fit this onto an XC7A50T in the final design, but the BRAM availability on the XC7A50T is just 75x 36Kb blocks vs the 365x 36Kb blocks available on the XC7A200T (of which I am using ~235, but also with ILAs and other devices which I will remove in the final design).
I don't really understand what are you trying to achieve to be honest. Can you please be more specific as to what are you trying to do?
\Vitis\xv_procss_example_2\Debug\xv_procss_example_2.elf is mapped to address range [00000000:00034BEB], but there is no memory available in that range. Make sure that the data file base address is set to an address corresponding to the memory address range in the design.
If I try to set them all to the DDR ram I get the error below…Quote\Vitis\xv_procss_example_2\Debug\xv_procss_example_2.elf is mapped to address range [00000000:00034BEB], but there is no memory available in that range. Make sure that the data file base address is set to an address corresponding to the memory address range in the design.
Sorry if my last post wasn’t clear.
If I try to set them all to the DDR ram I get the error below…Quote\Vitis\xv_procss_example_2\Debug\xv_procss_example_2.elf is mapped to address range [00000000:00034BEB], but there is no memory available in that range. Make sure that the data file base address is set to an address corresponding to the memory address range in the design.What exactly shows this error? Build? Programming? Attempting to lauch a debug session?
The error appears when I generate a new download.bit file under the programming option.
Board is a Digilent Nexys video and I program it over USB or by using MicroSD card where I simply need to put the ‘download.bit’ onto the card and it loads everything at power on.
It doesn’t make a difference, Vitis will not generate the ‘download.bit’ file so there is nothing to program the board with if I set the linker to have everything in DDR.
The issue is not the programming method, first need to figure out why the file is not generated when I set everything to DDR, then the programming will work either way. It already works both ways if I put the settings like my photo.
The issue absolutely is programming method - MicroSD card method can't download your executable straight into DDR memory, but Vitis can (via xdb). You might want to read more about mechanics of these processes so you will understand how they work, and what is the difference.
The reason this worked in the debugger by the way, was the debugger will place the elf into your memory (DDR in this case). Updatemem is used for BRAM. So, if you want to place this into BRAM, then place it in this in the LMB (the first one in the list).
You have 32KB of BRAM connected to the LMB. If your application is too big to fit here, then you would need to go back to Vivado an increase the BRAM size in the address editor.
You seem to be thinking this is done differently without the need to a ‘download.bit’ file, but that’s how it is done on my setup with 2022.2, the project.bit, project.mmi and ELF are all brought together into a ‘download.bit’ file and then I can put it on MicroSD or use Vitis to transfer over USB.
If it can’t even generate the download.bit file and save it to my pc then it can’t be programming method.
As I said before, I do not get this issue if I don’t load an ELF file into the program window and leave the microblaze set to ‘bootloop’ then do a ‘Run’ or ‘Debug’ command.
EDIT 2: Actually there may be a way with the SPI flash, but not sure if I can make it work with MicroSD (ie will it give me a single .bit file??), looks essentially the same as what you linked to above, I will take a proper look later.
I don't want to overwrite the QSPI on the Nexys Video and lose the demo (don't ask, my OCD just won't let me unless I HAVE to), and the Nexys Video XC7A200T FPGA has enough BRAM to manage the program.
1. Created a system diagram which includes DDR controller (DDR2 in my case), Microblaze, Timer, UART, EthernetLite (for 100 Mbit Ethernet) and Quad SPI (configured in "Performance Mode" and Quad).
2. Once generated bitstream and exported HW, went in Vitis and created a platform project based on that xsa file
3. Created a baremetal echo application using LwIp echo template. It's set to run from DDR (0x8000_0000).
4. Using "Xilinx -> Program Flash" menu item, converted the executable into SREC and burnt it into flash at offset 0x40_0000 (I have 128 Mbit flash, so 0x100_0000 bytes, full bitstream is 0x21_72F7 bytes).
5. Created another baremetal application using "SREC SPI Bootloader" template. It's automatically set to run off BRAM.
6. Opened blconfig.h file inside generated project and changed FLASH_IMAGE_BASEADDR to 0x00400000
7. Launched bootloader under debugger and observed what's going on.
I have configured my QSPI IP to be the same (performance mode and quad), but I am not sure how to connect it up properly. Can you upload a snip of your block diagram and how it is connected? I am a bit confused on the connections to the right in my image below (io0_i, io0_o, io0_t, etc).
set_property IOSTANDARD LVCMOS33 [get_ports {qspi_ss_io[0]}]
set_property IOSTANDARD LVCMOS33 [get_ports qspi_io0_io]
set_property IOSTANDARD LVCMOS33 [get_ports qspi_io1_io]
set_property IOSTANDARD LVCMOS33 [get_ports qspi_io2_io]
set_property IOSTANDARD LVCMOS33 [get_ports qspi_io3_io]
set_property PACKAGE_PIN C11 [get_ports {qspi_ss_io[0]}]
set_property PACKAGE_PIN B11 [get_ports qspi_io0_io]
set_property PACKAGE_PIN B12 [get_ports qspi_io1_io]
set_property PACKAGE_PIN D10 [get_ports qspi_io2_io]
set_property PACKAGE_PIN C10 [get_ports qspi_io3_io]
It’s clear that the ss pin on the BD goes to cs in the constraints file however I am still unsure on the data pins.
Should I connect io0_i, io0_o and io0_t all together then tie them to qspi_dw[0]??
That’s the part that is not clear, there are 3 pins on the BD for every 1 pin on the actual flash memory and constraints file. How are these 3 pins meant to interface with 1 pin on the QSPI flash?
SREC SPI Bootloader
FlashID=0x1 0x2 0x19
Loading SREC image from flash @ address: 00A00000
SREC SPI Bootloader
FlashID=0x0 0x0 0x0
Loading SREC image from flash @ address: 00A00000
Error in SREC line: 00000001srec line is corrupted