UartLite on Arty S7-25 crashing my microblaze application when reading characters from USB serial port

[dooglas77]

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

[dooglas77]

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.

Edited August 31, 2022 by dooglas77

[JColvin]

Hi @dooglas77,

I haven't attempted to directly debug your code nor have I worked with FreeRTOS, but what is your "check for buffer over flow" on line 156 accomplishing? It just seems to decrease the rx_count to one less than the pre-defined buffer size if rx_count has exactly reached the buffer size but with no check for if it overflowed.

The other thing that I know of specific to the UartLite IP is that it has a fixed FIFO size of 16 bytes which is not configurable; I saw your UART_BUFFER_SIZE is set to 255; although I do not know if that is relevant in your situation here.

What I would be attempting to do is run the debugger, pause the debugger/system, provide a large set of characters in your serial terminal (to simulate typing quickly, both with and without the carriage return/newline characters), and then go step by step with that data already "in the pipe" to see how your system responds to an increasingly large number of characters (and if they are received in the correct order or if some are missed).
One runtime error that you miss with this debugging methodology is if the serial terminal is still in middle of sending or receiving data to the host system before the processor goes onto the next step. In my own (incomplete, janky) board-to-board UART communication test I had to use the "XUartLite_IsSending" function to have the sytem wait until xil_printf finished.

Thanks,
JColvin

[Richm]

I also had a quick look at your code. It looks like you are setting a flag in the isr for the main loop when a character is available? This would be the same as polling ( blocking ) in the main loop with an extra layer added on top. What you want to do read characters in the isr into a double (ping-pong) buffer until the rx fifo is empty and then set a flag and switch buffers when the command framing character ( usually cr or lf ) is received. What I usually do is set the flag to 1 or 2 to tell the main loop which bank of the rx buffer to read. Also,  be aware that sending a string longer that 16 chars will cause blocking on the tx side. I skip the character echo and transmit a simple ack/nack ( "OK"/"Error" ) depending on the results of the command parser.

[dooglas77]

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

[JColvin]

I have not encountered the hard crash that you are describing where the system is unable to recover; my guess if you are able to replicate this when sending characters quickly is that either a buffer is overflowing or a pointer for the location in an array is going outside of that memory space and then affecting other parts of the system, which could create issues in the system.

Thanks,
JColvin

[dooglas77]

@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