dooglas77

It turns out the application I was using was actually running on the external DDR3 memory. With a simple SREC SPI Bootloader I've been able to get it all flashed and running.

Thanks for that info @JColvin I'll give that a try and let you know how it goes.

Hi, I'm following a couple different tutorials on flashing my microblaze application to the Arty S7-25 board's Quad SPI flash. They all follow the same basic steps as this one: https://community.element14.com/technologies/fpga-group/b/blog/posts/arty-s7-50-how-to-store-microblaze-program-in-the-quad-spi-flash-memory-from-vivado. Basically generate the bitstream from Vivado with a BIN file also being generated and compressed. Then import into Vitis to create a software application. Build the application in Vitis as an ELF file. Back in Vivado, set the ELF file as a constraint file for the Microblaze IP. Then regenerate the bitstream in Vivado. Program the Arty S7 board from Vivado using the newly generated BIN file. Now the board should automatically boot the Vitis application. On my side of things everything appears to work and the final step of flashing to the Quad SPI flash finishes successfully however my application does not actually boot. Any suggestions on steps I might be missing here? One thing I should note here is that LD6 is on after programming and also if I reset the board. Thanks, Doug

All sorted out. I had some issues in the OS abstraction layer that I had ported over from some similar code from an STM32 project. Thanks @JColvin and @Richm for the help.

@JColvin I think you're right regarding the buffer overflow idea. I tried this on a Xilinx Spartan 7 SP701 dev board using their example Microblaze hardware design and it's doing the same thing. Thanks, Doug

Thanks @JColvin and @Richm for your responses. The problem I'm running into that doesn't quite make sense to me is that when my program runs into this problem there doesn't seem to be a way to recover, I believe it's some sort of data exception. Have you encountered this at all with your use of the UartLite component? I may give the UART 16550 a try instead. I like the idea of using the "XUartLite_IsSending" function to know when the xil_printf is done sending data, I've noticed that printfs don't always have all the data make it from the board to my PC. I will try moving the receive functionality into my ISR also. Thanks, Doug

Hi, I have a Microblaze design connected to a UartLite instance running on my Arty S7-25, also running FreeRTOS. I'm running into a problem where occasionally when I receive characters from my PC, the application crashes. I can reliably reproduce the problem if I type characters fast. In my code, I'm echoing back the received character and when return/enter is typed it echos back the entire string received up to that point. It's meant to be a command line interface. Any ideas what I'm doing wrong with the UartLite instance? Code for the thread that does all the UartLite work is attached. debug_uart_thread.c